nspluginviewer priority on newer linux kernel

[koos vriezen]

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)

> 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

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

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

Br
Koos