Scheduler: Process priority fed back to parent?

[Timothy Miller]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/