nspluginviewer priority on newer linux kernel

[James Richard Tyrer]

koos vriezen wrote:
> 2007/8/16, James Richard Tyrer <tyrerj at acm.org>:
>> Konrad Rzepecki wrote:
>>>    Hi
>>>
>>> I have detected some problem witch cpu cycles starvation with nspluginviewer
>>> (KDE 3.5.7) probably related with new CFS scheduler (kernel 2.6.23-rcX). So
> 
> [..]
> That should definitely  be reported a the lkml and not here.
> 
> [..]
> 
>>> So I have idea, is possible to run plugins in active tab at nice 0 and others
>>> at 15? This should reduce slowdown to minimum and keep cpu usage in resonable
>>> level.
>>>
>> I have noticed a general problem with Konqueror "clogging up" when you
>> open several windows and/or several tabs.  It appears to me that *only*
>> the tab and/or window that has focus should be running.  Since the tabs
>> in a window are all running under one process, we need cooperative
>> multitasking here that works well.  The best would be if you had
>> preemption so that other tabs or windows could load in the background
>> but be instantly preempted when mouse (button press not just movement)
>> or keyboard input occurs.
> 
> Most CPU spend in khtml is for painting, so not for hidden tabs (at
> least it shouldn't)

That is what I said, 'it shouldn't'.

>> However, the nsplugin is a separate process and we need for Konqueror to
>> control it.  Since you can command Konqueror to stop animation, this
>> control channel appears to already exist.
> 
> Exactly, nsplugins has nothing to do with khtml blocking the code path

Perhaps that is true (regarding khtml), but it isn't what was said. 
What was said is the nsplugins block Konqueror from running.  I have 
observed in using KSysGuard.

>> The ideal solution would be that having multiple windows and/or tabs
>> open wouldn't slow things down at all except when a VM swap was
>> necessary.  As things are, the more windows and tabs you open, the
>> slower everything in Konqueror gets.
>>
>> The sad situation is that Linux isn't really designed to run a GUI (no
>> *NIX is) and it isn't really that good at doing it.  IIUC, a process can
>> only be actually stopped when it asks for input and receives none.  Yes,
>> the scheduler starts and stops it as it multi-tasks, but the process is
>> still scheduled to run till it is blocked when it asks for input.  So,
>> really, the GUI is doing cooperative multitasking.
> 
> What nonsense is that? A X11 gui program nicely waits in 'select' or
> 'poll'. Remember that the connection with the Xserver is a socket.
> Just ideal to also monitor other socket connections.

Which is what I said.  The socket is the place where the process listens 
for input.  The problem is that the process keeps running till it gets 
to that point.  What is needed is a way to improve listening so that you 
don't have to wait to generate input to the GUI.

>> You could improve this situation with multiple threads.  A small thread
>> accepting the input and doing the GUI menus and controlling a large
>> thread which actually does the work.  I have no idea how this would (or
>> could) be implemented in C++ although I am sure I have a text somewhere
>> that explains how to do it in a procedural language.
> 
> More non-sense ..

Yes, this is all nonsense.  <sarcasm> The problem doesn't exist so we 
shouldn't do anything about it.</sarcasm>

So, why don't you try it and try to confirm the problem before saying 
that it is nonsense.  Open three Konqueror windows with 10 tabs each and 
see what happens.  Note that if you have a 3 GHz CPU and 2 GB of memory, 
this probably isn't going to happen, KDE should also run on slower 
machines with less memory.

And, do you have a suggested solution other than the Ostrich Algorithm?

-- 
JRT