Re: Linux scheduler (fwd)
Keith Rohrer (kwrohrer@enteract.com)
Wed, 18 Feb 1998 17:26:56 -0600 (CST)
And lo, Adam McKee saith unto me:
> The approach I am taking to prevent starvation is intentionally simple:
> tasks can, due to starvation, be promoted beyond their "minimum"
> run-queue, all the way to run-queue 0. Sooner or later, they will be
> awarded a timeslice by the scheduler, and when that is used up, they will
> be returned to their minimum run-queue.
[snip]
> > *NEW* Tasks get promoted above their maximum priority, when
> > they suffer from starvation, but this is for one full timeslice
> > only... OTOH, when it never finishes a timeslice, it might just
> > remain in the high queue (so a +20 niced vi still get's good
> > performance :-) For this the max-wait might be multiplied
> > by the nice level the process is on.
>
> This is what I've done, but I immediately return the process to its
> minimum run-queue regardless of whether or not it uses its entire slice.
> The whole aim here is to allow the super-user to regain control of the
> machine, and prevent processes on run-queues > 0 from being totally
> starved.
So in other words, every so often a starving process will get promoted
to the top run queue, page fault (all its unshared pages having been
swapped out minutes ago, in all likelyhood), and fall back down to
the bottom queue again?
> In writing and maintaining this patch, I've gained appreciation of two
> things with respect to kernel scheduling algorithms:
>
> o it's easy to design beautiful solutions for specific scheduling
> situations, but the real art is to come up with an algorithm
> that achieves good all-around performance, and doesn't totally
> break down in "un-anticipated" scheduling scenarios.
You're aiming, I'm sure (as per stuff I probably snipped) at root doing
stuff like ps and kill; these might work, but wouldn't likely get
starved.
Keith
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu