public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Con Kolivas <kernel@kolivas.org>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.9-rc1-mm1
Date: Fri, 27 Aug 2004 11:43:32 +1000	[thread overview]
Message-ID: <412E91C4.5020901@yahoo.com.au> (raw)
In-Reply-To: <50490000.1093553473@flay>

Martin J. Bligh wrote:
> --On Thursday, August 26, 2004 21:07:39 +1000 Con Kolivas <kernel@kolivas.org> wrote:
> 
> 
>>Andrew Morton wrote:
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc1/2.6.9-rc1-mm1/
>>>
>>>
>>>- nicksched is still here.  There has been very little feedback, except that
>>>  it seems to slow some workloads on NUMA.
>>
>>That's because most people aren't interested in a new cpu scheduler for
>>2.6. The current one works well enough in most situations and people
>>aren't trying -mm to fix their interactive problems since they are few
>>and far between. The only reports about adverse behaviour with 2.6 we track down to "It behaves differently to what I expect" or applications with no (b)locking between threads suck under load. Personally I think the latter is a good thing as it encourages better coding, and the former is something we'll have with any alternate design.
> 
> 
> Well ... it'd be nice to know what nicksched was trying to fix. Then maybe
> we could try to measure it. There's lots of stuff in the changelog about
> what technical stuff was fiddled with ... but nothing I can see about what
> it was meant to acheive.
> 

It is supposed to be "as simple as possible and no simpler" approach to
the 2 array scheduler.

The current one has a lot of 'unfairness' and temporal dependencies. Eg,
"if a process has been in an interruptible sleep and woken from interrupt,
and has been previously marked as 'interactive' then blah. If it has been
in an uninterruptible sleep then do something completely different"
(I just made that up)

So, some people's watchdog process that is using *no* CPU get 50 second
latencies. And you get unfairness problems where one CPU hog is given twice
the amount of CPU time as another because it got marked as interactive long
ago.

Basically, the only inputs into nicksched are when a process sleeps and
when it runs. The only per-process state is basically how much it runs and
how much it sleeps. Everyone is treated the same.

The kernbench regression is something I don't take lightly though. I'll see
if I can get to the bottom of it.

  reply	other threads:[~2004-08-27  1:50 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-26  8:47 2.6.9-rc1-mm1 Andrew Morton
2004-08-26 11:07 ` 2.6.9-rc1-mm1 Con Kolivas
2004-08-26 14:28   ` 2.6.9-rc1-mm1 Jurriaan
2004-08-26 18:25     ` 2.6.9-rc1-mm1 Thomas Davis
2004-08-26 14:36   ` 2.6.9-rc1-mm1 Rafael J. Wysocki
2004-08-26 14:45     ` 2.6.9-rc1-mm1 Felipe Alfaro Solana
2004-08-26 15:35       ` 2.6.9-rc1-mm1 Rafael J. Wysocki
2004-08-26 16:38     ` 2.6.9-rc1-mm1 Con Kolivas
2004-08-26 20:36       ` 2.6.9-rc1-mm1 Rafael J. Wysocki
2004-08-26 20:55       ` 2.6.9-rc1-mm1 Martin J. Bligh
2004-08-26 23:19         ` 2.6.9-rc1-mm1 Con Kolivas
2004-08-26 23:43           ` 2.6.9-rc1-mm1 Martin J. Bligh
2004-08-27  0:37           ` 2.6.9-rc1-mm1 Nuno Silva
2004-08-27  0:46             ` 2.6.9-rc1-mm1 Con Kolivas
2004-08-27  0:51               ` 2.6.9-rc1-mm1 Martin J. Bligh
2004-08-27  0:55                 ` 2.6.9-rc1-mm1 Con Kolivas
2004-08-27  0:58         ` 2.6.9-rc1-mm1 Rick Lindsley
2004-08-27 20:54           ` 2.6.9-rc1-mm1 Rafael J. Wysocki
2004-08-27 21:54             ` 2.6.9-rc1-mm1 Rick Lindsley
2004-08-27 22:29               ` 2.6.9-rc1-mm1 Rafael J. Wysocki
2004-09-03 21:11               ` schedstat-2.6.8.1 [was: Re: 2.6.9-rc1-mm1] Rafael J. Wysocki
2004-09-08  7:09                 ` Rick Lindsley
2004-09-04 18:35               ` 2.6.9-rc1-mm1 Rafael J. Wysocki
2004-09-08  8:10                 ` 2.6.9-rc1-mm1 Rick Lindsley
2004-09-04 23:10               ` latency.c [was: Re: 2.6.9-rc1-mm1] Rafael J. Wysocki
2004-09-08  8:12                 ` Rick Lindsley
2004-09-08 12:02                   ` Rafael J. Wysocki
2004-08-26 20:51   ` 2.6.9-rc1-mm1 Martin J. Bligh
2004-08-27  1:43     ` Nick Piggin [this message]
2004-08-26 12:06 ` 2.6.9-rc1-mm1 Denis Vlasenko
2004-08-26 19:40   ` 2.6.9-rc1-mm1 Sam Ravnborg
2004-08-26 17:58 ` 2.6.9-rc1-mm1 (compile stats) John Cherry
2004-08-26 18:53 ` 2.6.9-rc1-mm1 - undefined references - [PATCH] Paolo Ornati
2004-08-28  8:54   ` Adrian Bunk
2004-08-28  9:45     ` Paolo Ornati
2004-08-26 22:46 ` 2.6.9-rc1-mm1 Rafael J. Wysocki
2004-08-26 22:50   ` 2.6.9-rc1-mm1 Andrew Morton
2004-08-26 23:53 ` 2.6.9-rc1-mm1 Tomasz Torcz
     [not found] ` <20040827043132.GJ2793@holomorphy.com>
2004-08-27 21:42   ` 2.6.9-rc1-mm1 William Lee Irwin III
2004-08-28  5:26 ` [0/4] standardized waitqueue hashing William Lee Irwin III
2004-08-28  5:31   ` [1/4] standardize bit waiting data type William Lee Irwin III
2004-08-28  5:35     ` [2/4] consolidate bit waiting code patterns William Lee Irwin III
2004-08-28  5:37       ` [3/4] eliminate bh waitqueue hashtable William Lee Irwin III
2004-08-28  5:38         ` [4/4] eliminate inode " William Lee Irwin III
2004-08-28  6:17     ` [1/4] standardize bit waiting data type Andrew Morton
2004-08-28  6:34       ` William Lee Irwin III
2004-08-28  6:40         ` Andrew Morton
2004-08-28  6:48           ` William Lee Irwin III
2004-08-28  9:20             ` William Lee Irwin III
2004-08-28  9:22               ` [2/4] consolidate bit waiting code patterns William Lee Irwin III
2004-08-28  9:23                 ` [3/4] eliminate bh waitqueue hashtable William Lee Irwin III
2004-08-28  9:24                   ` [4/4] eliminate inode " William Lee Irwin III
2004-08-28  9:43                   ` [3/4] eliminate bh " Andrew Morton
2004-08-28  9:34                 ` [2/4] consolidate bit waiting code patterns Andrew Morton
2004-08-28  9:51                   ` William Lee Irwin III
2004-08-28  9:39                 ` Andrew Morton
2004-08-28  9:51                   ` William Lee Irwin III
2004-08-28  9:18     ` [1/4] standardize bit waiting data type Christoph Hellwig
2004-08-28  9:20       ` William Lee Irwin III
2004-08-28  9:06 ` [patch] 2.6.9-rc1-mm1: megaraid_mbox.c compile error with gcc 3.4 Adrian Bunk
  -- strict thread matches above, loose matches on Subject: below --
2004-08-28 14:14 2.6.9-rc1-mm1 Sid Boyce
2004-08-28 15:22 ` 2.6.9-rc1-mm1 Hugh Dickins

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=412E91C4.5020901@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    /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