public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Arjan van de Ven <arjan@infradead.org>, Mark Lord <lkml@rtr.ca>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: CONFIG_IRQBALANCE for 64-bit x86 ?
Date: Fri, 23 Nov 2007 14:09:52 +0100	[thread overview]
Message-ID: <20071123130952.GA6320@elte.hu> (raw)
In-Reply-To: <200711221854.15516.nickpiggin@yahoo.com.au>


* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Ahh, hate to get off topic, but let's not perpetuate this myth. It 
> wasn't Con, or CFS, or anything that showed fairness is some great new 
> idea. Actually I was arguing for fairness first, against both Con and 
> Ingo, way back when the old scheduler was having so much problems.
> 
> Not that I am trying to claim the idea for myself. Fairness is like 
> the most fundamental and obvious behaviour for any sort of resource 
> scheduler that I have to laugh when people get "credited" with this 
> idea.

just out of curiosity (and to get my own sense of history corrected), do 
you remember in which thread you said that? (and even better, could you 
dig out any URLs for that thread?)

btw., the question was never really whether fairness was a good idea for 
a resource scheduler - the question was whether _strict fairness_ was a 
good idea for a general purpose OS (and the desktop in particular). My 
point back then was that strict fairness is not good enough and that we 
thus need the interactivity estimator - and i still maintain the first 
half of that position while conceding that i was wrong about the second 
part :-)

I dont think anyone was arguing for a scheduler with no fairness at all 
- but "fairness" indeed was more of an after-thought, not the driving 
principle.

Current CFS uses a modified "sleeper fairness" model (not a strict 
fairness model) via which we in essence replace the effect of the 
interactivity estimator with "sleeper fairness". So in essence we've 
replaced the O(1) scheduler's sleep average code with a deterministic 
sleep average code. This in turn also made the allocation of CPU time 
deterministic throughout. (which in other words can also be called "fair 
allocation of CPU time")

_That_ scheme seems to behave rather well in practice and i think i can 
take credit for _that_ bit ;-) [many people have hacked upon that 
concept and code since then so it's nowhere near "my code" anymore, of 
course.]

	Ingo

  reply	other threads:[~2007-11-23 13:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20  4:12 CONFIG_IRQBALANCE for 64-bit x86 ? Mark Lord
2007-11-20  4:15 ` Ismail Dönmez
2007-11-20  4:17 ` Nick Piggin
2007-11-20  4:29   ` Willy Tarreau
2007-11-20  4:37     ` Adrian Bunk
2007-11-20  5:24       ` Nick Piggin
2007-11-20  5:28         ` H. Peter Anvin
2007-11-20  5:37   ` Arjan van de Ven
2007-11-20  7:37     ` Nick Piggin
2007-11-20 14:47       ` Arjan van de Ven
2007-11-20 15:43         ` Nick Piggin
2007-11-20 19:07           ` Arjan van de Ven
2007-11-20 20:02             ` Mark Lord
2007-11-20 21:58               ` Arjan van de Ven
2007-11-20 23:17                 ` Mark Lord
2007-11-22  7:54             ` Nick Piggin
2007-11-23 13:09               ` Ingo Molnar [this message]
2007-11-25 10:03                 ` Nick Piggin
2007-11-20 15:47         ` Mark Lord
2007-11-20 15:52           ` Mark Lord
2007-11-20 16:02             ` Arjan van de Ven
2007-11-20 16:10               ` Mark Lord
2007-11-20 18:42               ` Mark Lord
2007-11-20 22:01         ` Ingo Molnar
2007-11-20 23:22           ` Mark Lord
2007-11-20 23:27             ` Ingo Molnar
2007-11-20 23:33               ` H. Peter Anvin
2007-11-20 23:47                 ` Ingo Molnar
2007-11-20 23:50                   ` H. Peter Anvin
2007-11-21  0:07                     ` Ingo Molnar
2007-11-21  0:20                       ` H. Peter Anvin
2007-11-21  0:36                         ` Ingo Molnar
2007-11-21  0:47                           ` H. Peter Anvin
2007-11-21  2:48                           ` Jeff Garzik
2007-11-21  2:59                             ` H. Peter Anvin
2007-11-20 23:28             ` H. Peter Anvin
2007-11-20 19:17   ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2007-11-21  2:22 Walt H

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071123130952.GA6320@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox