Messages in this thread | | | Date | Thu, 26 Jun 2003 23:54:35 -0700 | From | jw schultz <> | Subject | Re: O(1) scheduler & interactivity improvements |
| |
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/
| |