[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070318075807.GA3760@1wt.eu>
Date: Sun, 18 Mar 2007 08:58:07 +0100
From: Willy Tarreau <w@....eu>
To: Radoslaw Szkodzinski <astralstorm@...il.com>
Cc: linux-kernel@...r.kernel.org, Al Boldi <a1426z@...ab.com>,
Andrew Morton <akpm@...ux-foundation.org>,
William Lee Irwin III <wli@...omorphy.com>,
ck@....kolivas.org, Avi Kivity <avi@...o.co.il>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Nicholas Miell <nmiell@...cast.net>
Subject: Re: [ck] Re: is RSDL an "unfair" scheduler too?
On Sun, Mar 18, 2007 at 07:54:20AM +0100, Radoslaw Szkodzinski wrote:
> On 3/18/07, Mike Galbraith <efault@....de> wrote:
> >On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:
> >
> >> Maybe we're all discussing the problem because we have reached the point
> >> where we need two types of schedulers : one for the desktop and one for
> >> the servers. After all, this is already what is proposed with preempt,
> >> it would make sense provided they share the same core and avoid ifdefs
> >> or unused structure members. Maybe adding OPTIONAL unfairness to RSDL
> >> would help some scenarios, but in any case it is important to retain
> >> the default fairness it provides.
> >
> >Bingo.
> >
>
> Sounds like Staircase's interactive mode switch, except this actually
> requires writing additional code.
>
> The per-user system would also be nice for servers, provided there are
> CPU/disc IO/swapper/... quotas or priorities at least.
This is too hard to adjust. Imagine what would happen to your hundreds of
apache processes when the "backup" user will start the rsync or tar+gzip,
or when user "root" will start rotating and compressing the logs. Being
able to group processes may be useful on servers, but it should be enabled
on purpose by the admin.
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists