Re: [2.4.17/18pre] VM and swap - it's really unusable

Daniel Phillips (phillips@bonn-fries.net)
Tue, 15 Jan 2002 04:31:36 +0100


On January 15, 2002 04:07 am, george anzinger wrote:
> Daniel Phillips wrote:
> >
> > On January 14, 2002 10:09 am, yodaiken@fsmlabs.com wrote:
> > > UNIX generally tries to ensure liveness. So you know that
> > > cat lkarchive | grep feel | wc
> > > will complete and not just that, it will run pretty reasonably because
> > > for UNIX _every_ process is important and gets cpu and IO time.
> > > When you start trying to add special low latency tasks, you endanger
> > > liveness. And preempt is especially corrosive because one of the
> > > mechanisms UNIX uses to assure liveness is to make sure that once a
> > > process starts it can do a significant chunk of work.
>
> If I read this right, your complaint is not with preemption but with
> scheduler policy. Clearly both are needed to "assure liveness".
> Another way of looking at preemption is that is enables a more
> responsive and nimble scheduler policy (afterall it is the scheduler
> that decided that task A should give way to task B. All preemption does
> is to allow that to happen with greater dispatch.) Given that, we can
> then discuss what scheduler policy should be.

You responded to the wrong person, however I'll take this opportunity to
agree with you, on the basis of my years of experience with critical path
scheduling. For project schedules 'earlist completion' is the name of the
game, within bounds of available resources. When you delay an indvidual
'task' (I'm using the project management term here) past the earliest time it
can be scheduled, you are using up its 'float', and if the delay is longer
than the task's float, the completion time of the schedule as a whole will be
delayed. This is no different for a computer than it is for a group of
people, it is still a scheduling problem. Delaying any random task risks
delaying the schedule as a whole, and that risk approaches certainty as the
number of delays approaches infinity.

N.B.: the above observation is aimed at project managers, who will know
exactly what I'm talking about. Otherwise, don't worry if it sounds like so
much BS, it actually isn't ;-)

--
Daniel
-
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/