> 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...
This is the case which worries me, passing back the priority of the
process which is waiting for user input. It's desirable, but hard to do
and subject to unintended boosts.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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/