Peter Humphrey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
