nspluginviewer priority on newer linux kernel

[Stefanos Harhalakis]

On Thursday 16 August 2007, James Richard Tyrer wrote:
> Stefanos Harhalakis wrote:
> > On Thursday 16 August 2007, James Richard Tyrer wrote:
> >> 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.
> >
> >   For what you're describing, it can also be stopped by receiving a
> > SIGSTOP signal (and continue using a SIGCONT) or when waiting for a
> > semaphore. It can also sleep for a very long period of time (using
> > sleep()) and wake up by a signal.
>
> Yes, exactly.  The problem is that you need one process to send these
> signals to the other process.  IIUC, listening at a socket doesn't
> accomplish this.  That is to find out that the window doesn't have focus
> and stop using the CPU.

  I can't say I completely understand what you're saying. Listening to a 
socket and waiting for user input (or X11 data) is the same thing since these 
actions depend on a read() or a select() on one or more FDs. A process may 
voluntarily stop running without waiting for an event either by calling 
sleep(), calling sched_yield() (not a good practice) or terminating. What 
else should exist?

  Perhaps you should experiment with /proc/sys/kernel/sched_granularity_ns to 
tune CFS. Apart from that, I recommend running 'top' where you can see 
the 'PR' column where the adjusted priority is displayed. No matter what 
the 'nice' value is, the actual priority may defer, depending on various 
factors.