lkml.org 
[lkml]   [2004]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectScheduler: Process priority fed back to parent?
Something occurred to me, so it has probably occurred to others as well.  :)

Anyhow, the idea that I had was to feed information about a process's
behavior (interactive/not) to the process's parent (and it's parent,
etc). The next time the parent forks, that information is used to
initially estimate the priority of the forked process.

This isn't perfect, but it would help distinguish between a user shell
where compiles are being done and a user shell (say, Gnome) from which
interactive processes are being launched. Each process maintains a
number which indicates the trends seen in the interactivity of its
descendents.


Another idea I had, but which I think I've seen discussed before, was to
cache information about individual executables. Every time a process
terminates (and/or periodically), the behavior of that process is fed to
a daemon which stores it on disk (on a periodic basis) in such a way
that the kernel can efficiently get at it. When the kernel launches a
process, it looks at the cache for interactivity history to estimate
initial priority.

This way, after gcc has run a few times, it'll be flagged as a CPU-bound
process and every time it's run after that point, it is always run at an
appropriate priority. Similarly, the first time xmms is run, its
interactivity estimate won't be right, but after it's determined to be
interactive, then the next time the program is launched, it STARTS with
an appropriate priority: no ramp-up time.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2011 Jasper Spaans