Nehalem

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
[email protected]                   University of Alabama at Birmingham
(205) 934-2213                  136A Campbell Hall
(205) 934-5473 FAX              Birmingham, AL 35294-1170