Re: O(1) scheduler & interactivity improvements
jw schultz (jw@pegasys.ws)
Thu, 26 Jun 2003 23:54:35 -0700
On Thu, Jun 26, 2003 at 11:59:36AM +0200, Helge Hafting wrote:
> How about _removing_ the io-wait bonus for waiting on pipes then?
> If you wait for disk io, someone else gets to use
> the cpu for their work. So you get a boost for
> giving up your share of time, waiting
> for that slow device.
>
> But if you wait for a pipe, you wait for some other
> cpu hog to do the first part of _your_ work.
> I.e. nobody else benefitted from your waiting,
> so you don't get any boost either.
>
> This solves the problem of someone artifically
> dividing up a job, using token passing
> to get unfair priority.
>
> This can be fine-tuned a bit: We may want the pipe-waiter
> to get a _little_ bonus at times, but that has to be
> subtracted from whatever bonus the process at the
> other end of the pipe has. I.e. no new bonus
> created, just shift some the existing bonus around.
> The "other end" may, after all, have gained legitimate
> bonus from waiting on the disk/network/paging/os, and passing
> some of that on to "clients" might make sense.
>
> So irman and similar pipe chains wouldn't be able to build
> artifical priority, but if it get some priority
> in an "acceptable" way then it is passed
> along until it expires.
>
> I.e. "bzcat file.bz2 | grep something | sort | less" could
> pass priority down the chain when bzcat suffers
> a long nfs wait...
You don't want to penalise pipes either. I can just imagine
some nutcase shifting from pipes to a less efficient
communications channel to shave 5% off his run time.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: jw@pegasys.ws
Remember Cernan and Schmitt
-
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/