[lkml]   [2004]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.019 / U:12.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site