[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070318052439.GT943@1wt.eu>
Date: Sun, 18 Mar 2007 06:24:40 +0100
From: Willy Tarreau <w@....eu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: William Lee Irwin III <wli@...omorphy.com>,
Avi Kivity <avi@...o.co.il>, Ingo Molnar <mingo@...e.hu>,
Con Kolivas <kernel@...ivas.org>, ck@....kolivas.org,
Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
Al Boldi <a1426z@...ab.com>, Mike Galbraith <efault@....de>,
linux-kernel@...r.kernel.org, Nicholas Miell <nmiell@...cast.net>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: is RSDL an "unfair" scheduler too?
On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 17 Mar 2007, William Lee Irwin III wrote:
> >
> > One issue this raises is prioritizing users on a system, threads within
> > processes, jobs within users, etc.
>
> Doing some "classing" even by just euid might be a good idea. It would
> actually catch X automatically most of the time, because the euid of the X
> server is likely to be root, so even for the "trivial" desktop example, it
> would kind of automatically mean that X would get about 50% of CPU time
> even if you have a hundred user clients, just because that's "fair" by
> euid.
Warning: all these ideas seem interesting for desktop, but are definitely
not for servers. I found RSDL to be excellent on servers, compared to
mainline in which some services are starving under load. I can understand
that on the desktop people want some unfairness, and I like the pgrp idea
for instance. But this one will certainly fail on servers, or make the
admins get grey hair very soon.
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.
> Dunno. I guess a lot of people would like to then manage the classes,
> which would be painful as hell.
Sure ! I wouldn't like people to point the finger on Linux saying "hey
look, they can't write a good scheduler so you have to adjust the knobs
yourself!". I keep in mind that Solaris' scheduler is very good, both
fair and interactive. FreeBSD was good (I haven't tested for a long time).
We should manage to get something good for most usages, and optimize
later for specific uses.
Regards,
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