[lkml]   [1998]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: a different approach to scheduling issues

    On 01-Oct-98 Rik van Riel wrote:
    > The main problem is that the scheduling code is very
    > time critical. It is one of the main performance
    > loopholes for every Unix in existance, so we need to
    > make it as fast as possible.

    Actually, scheduling isn't especially time-critical, but context switching is.

    It's quite common for systems to only recalculate priorities every second or
    so, even if they're switching contexts much more rapidly. This allows you to
    do more interesting/complex scheduling decisions without everything bogging
    down. Maybe you could even run the scheduler in user-mode as an RT task...

    The way I'd do it is have "schedule()" not control priorities at all, but
    simply maintain accurate and precise info (and I mean *accurate* and *precise*
    - use the cycle counter to measure how much of a time-slice was used, if that's
    an option) on what each process has done. Every now and then (a tunable which
    depends on how responsive you need your dynamic priorities to be) you go
    through and recalculate the relative importance of your running processes.

    RT processes, of course, never have their priorities changed, so the scheduler
    is essentially a no-op. Sleeping processes never need their priorities
    adjusted until they actually become runnable.

    Ideally you'd get rid of the idea of a priority number too, and just have the
    scheduler decide on the relative importance of two processes, which would
    control ordering on the run queue. This gets rid of all kinds of problems
    which affect more complex schedulers which can't easily map process importance
    into a limited integer range.

    So, yeah, I think a carefully designed scheduler interface has the potential to
    be both very flexible and efficient.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.022 / U:40.692 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site