nspluginviewer priority on newer linux kernel

[James Richard Tyrer]

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 
> there is much more cpu cycles given to higher prority task (i.e. 
> compilation). Default nice=15 is to low now. Even if I set nice of 
> compilation to 10 nsplugin is almost unusable. Setting to 15 cause to run ns 
> bad but acceptable. 16 is almost somooth but not ideal. With nice 20 set 
> compilation is OK. 

Actually, '19' is supposed to be the lowest priority.

> Tested with youtube movies.
> 
> More experienced users probably detect problem and fix it by setting nice to 
> right levels. But beeginers will be confused, or may by even discouraged to 
> konqueror.
> 
> Setting ns... nice to 0 is also bad idea, because flash in nth of tabs running 
> at 100% cpu, will kill the system.

Yes, I have noticed that and have to resort to killing all of them.

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

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.

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.

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.

-- 
JRT