From: Robert Hyatt <hyatt@cis.uab.edu>
To: linux-smp@vger.kernel.org
Subject: Nehalem
Date: Tue, 24 Mar 2009 13:05:51 -0500 (CDT) [thread overview]
Message-ID: <Pine.LNX.4.63.0903241259530.15698@localhost.localdomain> (raw)
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.
Robert M. Hyatt, Ph.D. Computer and Information Sciences
hyatt@uab.edu University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170
next reply other threads:[~2009-03-24 18:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 18:05 Robert Hyatt [this message]
2009-03-25 12:32 ` Nehalem Bill Davidsen
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=Pine.LNX.4.63.0903241259530.15698@localhost.localdomain \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).