[lkml]   [2003]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [SHED] Questions.
    On Sun, 2003-08-31 at 06:07, Ian Kumlien wrote:

    > Why not use small quantum values for high pri processes and long for low
    > pri since the high pri processes will preempt the low pri processes
    > anyways. And for a server working under load with only a few processes
    > (assuming they are all low pri) would lessen the context switches.

    The rationale behind giving high priority processes a large timeslice is

    (1) if they are interactive, then they won't actually use it all (this
    is the point you are making). But,

    (2) Having a large timeslice ensures that they have a high probability
    of having available timeslice when they _do_ need it.

    So, yes, interactive processes can get by with a small timeslice,
    because that is by-definition all they need. But they do need to run
    often (i.e., as I think you have mentioned in your last email,
    interactive processes are "run often for short periods"), so the large
    timeslice ensures that they are never expired.

    A counterargument might be that the large timeslice is a detriment to
    other high priority processes. But the thinking is that, by definition,
    interactive processes won't use all of the timeslice. And thus will not
    hog the CPU. If they do, the interactivity estimator will quickly bring
    them down.

    That is the rationale in the current scheduler, anyhow. Nick's current
    work is interesting, and a bit different.

    > And a system with "interactive load" as well would, as i said, preempt
    > the lower pris. But this could also cause a problem... Imho there should
    > be a "min quantum value" so that processes can't preempt a process that
    > was just scheduled (i dunno if this is implemented already though).

    I don't think this is a good idea. I see your intention, but we have
    priorities for a reason.

    Robert Love

    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 13:48    [W:0.039 / U:9.820 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site