nspluginviewer priority on newer linux kernel

[koos vriezen]

2007/8/16, James Richard Tyrer <tyrerj at acm.org>:
> 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'.

And does it do repaints on hidden tabs? (I don't mean the plugins).
Slow DCOP communication might block khtml though.

> >> 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.

Using either a timer signal or a timeout, you don't need input to jump
out of this listening state.

> >> 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>

I simply don't see what 'improving input' has to do with improving the
situation.

The flash player on Linux definitely uses too much CPU (comparing to
eg. MPlayer playing the same movie) and apparently doesn't handle the
cases where it lacks behind timer events in a user experience pleasing
way.
(I've added a note on my virtual TODO list whether the flash plugin
can be notified about being visible or not)

> 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.

Yes but if demands are getting higher, so should the hardware. SMP
users know this for ages, but multicore really helps.

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

Yes funny, I always say denial is the first step in solving :-)

Koos