But a process may or may not be "interactive"

Posted Mar 13, 2003 19:12 UTC (Thu) by captrb (guest, #2291)
In reply to: Process "interactive" bits by NAR
Parent article: Improving interactivity on Linux systems

A process may or may not be interactive depending on how it is used, not how it is
constructed. A relatively unused apache instance, usually sleeping but
occasionally awaking would be an interactive process. In this situation you want
apache given priority to finish its job and resume sleeping, taking momentary
priority over the non-sleeping seti@home process that has been sucking CPU for
weeks.

What this patch does above and beyond this is to share priority with process that
the interactive process is IO bound on. So if the awoken apache process contacts
the seti@home process (I don't know why it would, but for the example) and is
waiting for a response, you actually want to give the seti@home process some of
apache's priority. Giving more cpu time to apache at this point is useless, as he is
just waiting for seti@home to respond, you may as well identify the relationship
and help apache finish its request by helping out seti.

The reason this relates to the an Xserver and "user interactive" processes is that
all Xwindows programs (like the Gnome and KDE programs you suggest have the
interactive bit set) are clients to the xserver. Even if they are given priority, they
still have to wait for the xserver to perform the display duties. Giving more priority
to them doesn't help, as they are IO bound and gagged. Furthermore, those
xclient programs could be pigs, sucking cpu without user interaction. If you
depended on the "interactive bit" being set, you'd never be able to properly
de-prioritize a "interactive bit" application that had spiraled out of control.
Contrary to what a good scheduler should do, you'd be giving too much time to the
process that doesn't need it.