[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.98.0704181302370.2828@woody.linux-foundation.org>
Date: Wed, 18 Apr 2007 13:11:12 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Davide Libenzi <davidel@...ilserver.org>
cc: Ingo Molnar <mingo@...e.hu>, Matt Mackall <mpm@...enic.com>,
Nick Piggin <npiggin@...e.de>,
William Lee Irwin III <wli@...omorphy.com>,
Peter Williams <pwil3058@...pond.net.au>,
Mike Galbraith <efault@....de>,
Con Kolivas <kernel@...ivas.org>, ck list <ck@....kolivas.org>,
Bill Huey <billh@...ppy.monkey.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair
Scheduler [CFS]
On Wed, 18 Apr 2007, Davide Libenzi wrote:
>
> "Perhaps on the rare occasion pursuing the right course demands an act of
> unfairness, unfairness itself can be the right course?"
I don't think that's the right issue.
It's just that "fairness" != "equal".
Do you think it "fair" to pay everybody the same regardless of how good a
job they do? I don't think anybody really believes that.
Equating "fair" and "equal" is simply a very fundamental mistake. They're
not the same thing. Never have been, and never will.
Now, there's no question that "equal" is much easier to implement, if only
because it's a lot easier to agree what it means. "Equal parts" is
somethign everybody can agree on. "Fair parts" automatically involves a
balancing act, and people will invariably count things differently and
thus disagree about what is "fair" and what is not.
I don't think we can ever get a "perfect" setup for that reason, but I
think we can get something that at least gets reasonably close, at least
for the obvious cases.
So my suggested test-case of running one process as one user and two
processes as another one has a fairly "obviously correct" solution if you
have just one CPU's, and you can probably be pretty fair in practice on
two CPU's (there's an obvious theoretical solution, whether you can get
there with a practical algorithm is another thing). On three or more
CPU's, you obviously wouldn't even *want* to be fair, since you can very
naturally just give a CPU to each..
Linus
-
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