public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Valdis.Kletnieks@vt.edu
Cc: root <swordfish@onetbd.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Scheduler: Improving the scheduler performance.
Date: Sun, 08 Apr 2007 22:12:17 -0400	[thread overview]
Message-ID: <4619A101.5030600@redhat.com> (raw)
In-Reply-To: <8762.1176044803@turing-police.cc.vt.edu>

Valdis.Kletnieks@vt.edu wrote:
> On Sat, 07 Apr 2007 23:42:20 +0600, root said:
> 
>> As we know that, linux scheduler use separate runqueue for every CPU of
>> a multiprocessor system, which having an active and an expired array.If
>> we use only one expired array, then the CPUs of a multiprocessor system
>> will be able to share their expired task via the accumulated expired
>> array,
> 
> I got this far, and the first thought that popped into my head was:
> 
> "Wow.  This might actually win on a UP or small MP (2-15 CPU).  But the
> lock contention on a big 512-CPU machoflops box is likely going to *suck*".
> 
> For that matter, my quick eyeballing of the code, although it doesn't *find*
> any race conditions, doesn't convince me there's any protection taken to make
> sure there aren't any.  Is there some subtle algorithmic trick I'm missing
> to ensure Nothing Bad Can Happen?

Lock contention is going to be the least of your worries.

Destroying CPU affinity is the big one I suspect.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

      reply	other threads:[~2007-04-09  2:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-07 17:42 [PATCH] Scheduler: Improving the scheduler performance root
2007-04-08 15:06 ` Valdis.Kletnieks
2007-04-09  2:12   ` Rik van Riel [this message]

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=4619A101.5030600@redhat.com \
    --to=riel@redhat.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swordfish@onetbd.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