On Wednesday 17 May 2006 19:49, Mike Galbraith wrote:
> On Wed, 2006-05-17 at 18:23 +1000, Con Kolivas wrote:
> > There is a ceiling to the priority beyond which tasks that only ever
> > sleep for very long periods cannot surpass.
>
> (Hmm. The intent is more clear, ie reserve the top for low latency
> tasks,... but that sounds a bit like xmms protection.)
>
> The main problem I see with this ceiling, solely from the interactivity
> viewpoint, is that interactive tasks which have started burning cpu
> and/or freshly forked interactive tasks land in the same spot. Thud.c
> demonstrates this problem quite well. You don't want a few copies of
> thud in the same queue with your interactive task, much less above it if
> it's used enough cpu to drop a notch or two. Much pain ensues.
If there are thud processes that have earned their place they deserve it, just
as any other task. If something uses only 1% cpu it is unfair just because it
only ever sleeps for long sleeps to prevent it getting as good priority as
anything else that uses only 1% cpu. I've noticed that 'top' suffers this
fate for example. The problem I've had all along with thud as a test case is
that while it causes a pause on the system for potentially a few seconds, it
does this by raising the load transiently to a load of 50 (or whatever you
set it to). I have no problem with a system having a hiccup when the load is
50, provided the system eventually recovers and isn't starved forever (which
it isn't). There are other means to prevent one user having that many running
tasks if so desired.
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
