[gentoo-amd64] Re: Identifying CPUs in the kernel

[Duncan]

Peter Humphrey <prh@××××××××××.uk> posted
200706221910.44194.prh@××××××××××.uk, excerpted below, on  Fri, 22 Jun
2007 19:10:44 +0100:

>> What I'm wondering, of course, is whether you have NUMA turned on when
>> you shouldn't, or don't have core scheduling turned on when you should,
>> thus artificially increasing the resistance to switching cores/cpus and
>> causing the stickiness.
>
> I don't think so.

Yeah, now that you've clarified that it's sockets and confirmed settings, 
you seem to have it right.

On the BIOS settings, some of them will affect whether the board can use 
all four gigs memory as well, by controlling how it arranges the address 
space and whether there's a hole left between 3.5 and 4 gig for 32-bit 
PCI hardware addressing or not.  I've a similar arrangement here on a 
Tyan s2885, only with two-gig sticks so 8 gig memory.  If you are seeing 
your full 4 gig memory, tho, you've got that set right, both in the 
kernel and in the BIOS.

The other BIOS settings of interest here are the access bitness/
interleaving.  If it's like mine, you'll be able to set 32-, 64-, or 128-
bit interleaving.  You'll want 64-bit, interleaving the sticks in the 
node for best bandwidth there, but not the nodes, so they can be used 
NUMA.  In ordered to actually get the 64-bit interleaved access, you'll 
need the sticks in paired slots on the node, however.  (1&2 or 3&4, not 
2&3 or separated.)  But it sounds like you have that as well.

Finally, there's the question of how the rest of the system connects to 
the sockets.  Here, everything except memory all connects to the first 
socket (CPU0), so the system can run in single socket mode.  However, 
that means anything doing heavy I/O or the like, including 3D video 
access, runs most efficient on CPU0.  In particular, using taskset 
(mentioned in what I snipped), I've noticed that even in 2D mode but with 
Composite on, X takes several percentage points more CPU when it's 
scheduled on CPU1 than it does when it's allowed to run on CPU0.  CPU1 
works best with CPU or hard drive or other comparatively slow I/O bound 
processes, the former since it doesn't matter which CPU for them, the 
latter since the I/O is slow enough it's the bottleneck in any case. If 
your board is laid out similarly, when you are playing around with 
taskset or the like, it's worth keeping that in mind.

If as you say, BOINC is running separate processes, than scheduling it 
with taskset should be possible and do what you need to do.  The only 
caveat would be if the processes terminate and restart.  You may need to 
hack a script up to run from cron, to check every minute or 10 or 
whatever, depending on how long the BOINC tasks last, to keep them 
scheduled on separate CPUs.  I have a particular game (Master of Orion 
original, the only non-source based software I still run) I run in DOSBOX 
emulation.  Mainly, I use taskset to set DOSBOX on CPU1, while X and 
anything else I'm running that uses significant CPU gets put on CPU0.  
That works VERY well, and has allowed me to increase the emulation speed 
dramatically over that possible before, when X and DOSBOX may have been 
running on the same CPU.  That's the big thing I use taskset for, but it 
works quite well for it. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list