All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@gmail.com>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: Are we properly prepared to handle 3 Socket setups?
Date: Sun, 12 Aug 2007 05:17:10 +0200	[thread overview]
Message-ID: <46BE7BB6.2010607@gmail.com> (raw)
In-Reply-To: <9a8748490708111852y569a3e18i1c3d192e60eceafe@mail.gmail.com>

On 08/12/2007 03:52 AM, Jesper Juhl wrote:

> On 12/08/07, Rene Herman <rene.herman@gmail.com> wrote:
>> On 08/12/2007 03:08 AM, Jesper Juhl wrote:
>>
>>> This may be a little off topic, but I think it's interresting enough
>>> to warrent a single mail.
>>>
>>> I just saw a news article (http://www.theinquirer.net/?article=41610)
>>> about a 3 Socket Opteron motherboard and couldn't help but wonder if
>>> we are prepared to deal with such a beast, so I thought I'd inform
>>> everyone :-)
>>>
>>> I'm guessing equipping such a board with 3 single core CPU's could
>>> show up some interresting corner cases in schedular code and
>>> elsewhere, I'll bet we have some assumptions somewhere about
>>> nr_of_cpus being an even number...
>> I would hope the N=1 case will have flushed out enough of those... :-|
>>
> Hehe, true, but I was thinking more of nr_of_cpus is an odd number > 1. :-)
> Just thinking of having to divide things by 3 makes me worry ;-)  ...

It's not a hugely strange worry no. Grepping around (for num_online_cpus for 
example) didn't throw up any glaring bugs I believe.

A possible problem in mm/vmstat.c:calculate_threshold() where 3 CPUs would 
be treated as 2 through an fls(). No idea about that code and if that would 
be a problem.

The line just below where it does that _does_ seem to have a problem:

         /*
          * Maximum threshold is 125
          */
         threshold = min(125, threshold);

as either the comment or the code is wrong and it seems it's the code. Added 
Andrew Morton to the CC for that.

CFS (v19.1) has an ilog2 on num_online_cpus() in 
kernel/sched.c:sched_init_granularity() but this seems not a problem. Added 
Ingo Molnar.

Rene.

  reply	other threads:[~2007-08-12  3:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-12  1:08 Are we properly prepared to handle 3 Socket setups? Jesper Juhl
2007-08-12  1:27 ` Rene Herman
2007-08-12  1:52   ` Jesper Juhl
2007-08-12  3:17     ` Rene Herman [this message]
2007-08-12  3:29       ` Roland Dreier
2007-08-12  3:36         ` Rene Herman
2007-08-12  8:35       ` Andrew Morton
2007-08-12 20:00         ` Rene Herman
2007-08-13 20:44           ` Christoph Lameter
2007-08-12  7:24     ` Paul Mundt
2007-08-12  8:41   ` Willy Tarreau
2007-08-12 11:46 ` Andi Kleen

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=46BE7BB6.2010607@gmail.com \
    --to=rene.herman@gmail.com \
    --cc=akpm@osdl.org \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.