All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Robert Hyatt <hyatt@cis.uab.edu>
Cc: linux-smp@vger.kernel.org
Subject: Re: Nehalem
Date: Wed, 25 Mar 2009 08:32:45 -0400	[thread overview]
Message-ID: <49CA246D.7080105@tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0903241259530.15698@localhost.localdomain>

Robert Hyatt wrote:
>
> I ran into an issue that may or may not be on the radar.  Here goes:
>
> 1.  The old hyperthreading fix works well for an old PIV with 
> hyperthreading, so that with two sockets, and 4 logical processors, 
> the compute-bound processes get balanced across the sockets, which 
> fixed the original hyper-threading bug everyone talked about.
>
> 2.  I now have a dual-socket Nehalem box, 4 cores per socket.  Someone 
> wanted to test hyper-threading, which I had disabled, and I found an 
> issue.
>
> It appears that the current process scheduling works fine for 
> balancing compute-bound processes across the two sockets to optimize 
> cache usage. But with hyper-threading, things go wrong.  If I run 4 
> compute-bound processes on this box, they will run two per socket just 
> fine.  But on any one chip, it is probable that the two processes will 
> land on the same core, which is not good.
>
> My first thought was this needs a hiararchical approach.  one big run 
> queue per socket, then N run queues per socket, one per physical core.
>
> Now the load can be balanced across the two sockets / chips using the 
> "high-level" pair of queues, and then balanced across the physical 
> cores on each socket using the low-level queues, to avoid running two 
> processes on one physical core, and none on another.
>
> Is a fix already in the works for this, or is this a new issue?  I am 
> running 2.6.28.8 on this box.  I am also not so happy with turbo-boost 
> either as it is giving some erratic timing data which I don't like for 
> my benchmark and tweak software development.  But that's another 
> issue. not kernel-related.

This might be an issue for me as well, I've just ordered parts to build 
several servers based on the i7 architecture, so I will have four cores 
+ HT although they will all be in a single socket. I don't have any idea 
how well this will work, I suppose the HT can be turned off if needed, 
and it will run as well as the Q6600 system these will replace.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc

"You are disgraced professional losers. And by the way, give us our money back."
    - Representative Earl Pomeroy,  Democrat of North Dakota
on the A.I.G. executives who were paid bonuses  after a federal bailout.



  reply	other threads:[~2009-03-25 12:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-24 18:05 Nehalem Robert Hyatt
2009-03-25 12:32 ` Bill Davidsen [this message]
2009-03-25 13:58   ` Nehalem Robert Hyatt

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=49CA246D.7080105@tmr.com \
    --to=davidsen@tmr.com \
    --cc=hyatt@cis.uab.edu \
    --cc=linux-smp@vger.kernel.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 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.