>>I'm running a 24-job batch (actually 120 in all, in five cycles) on a
>>24-CPU Sun Fire 6800 box with 48G RAM, and the CPU Usage is more than
>>90% when there are 24 jobs running. Since these jobs are extremely CPU
>>intensive, would it help to allocate these jobs individually to CPU's
>>or groups of these to processor sets? I'm thinking about what kind of
>>saving could be made out of saving switches for time sharing. I should
>>mention however, that these processes also do significant I/O,
>>although we have seen extremely encouraging (I'm told) response times
>>(ave 1.6 milliseconds or so). Would the gains made by avoiding the
>>switches be offset by increased idle times? If anyone has specific
>>experience in this regard, I would appreciate their inputs (any
>>response is welcome, though).
> Just off the top of my head, I'd assume no. The scheduler is already
> going to try to keep things local to some extent.
A thread has affinity to the cpu it last ran on if it ran "recently".
Otherwise a new one is selected according to various rules. In Solaris 9
(and 8 too after some KU, I *think*) there is also knowledge of
latency groups in a system like the SF6800 (the 4 cpus on a single
SB form a single latency group). A thread is allocated a home
latency group and an effort is made to try and perform some of
it's memory allocations from that latency group. Threads then
prefer to run in their home latency group, unless that's very busy
and some other group looks idle.
These general rules (much simplified above) cope reasonably well with
disparate workloads. It's possible that if you have a very predictable
and static workload that you assign cpus better through pbind or
The mpstat output has information on voluntary and involuntary
context switches (csw and icsw). The former are typically where
you block for IO etc. The latter are where you are forced off
in favour of someone more deserving. You can't really see
cpu migrations of a thread without something like Dtrace, but
you can 'prstat 0' and watch which cpus a process runs on and
see how much it moves around.