Process binding on Dual P4 Xeon

Process binding on Dual P4 Xeon

[Simon Oliver]

I have recently installed a new dual P4 Xeon system.

For a particularly computeintensive program I have been advised to turn of
hyperthreading in the BIOS, so now Linux sees two CPUs instead of four
logical CPUs - makes sense :-)

I know that the binding of a process to a cpu is "loose" under linux (as
apposed to Irix say) and one expects jobs to hop between CPUs every now
and then.

But I have been monitoring (via top) a simple perl script (no forks or
threading involved) and not only does it switch CPU, sometimes it seems to
split accross the CPUs with 50% utilization on each CPU, or even a 25/75
split.  I have never noticed this before on dual CPU machines (I have a
few dual PIIIs).

The machine is still running the SuSE supplied SMP kernel:

Linux version 2.4.18-64GB-SMP (root@SMP_X86.suse.de) (gcc version 2.95.3
20010315 (SuSE)) #1 SMP Wed Mar 27 13:58:12 UTC 2002

Please enlighten me.

-- 
  Simon Oliver

Re: [SLE] Process binding on Dual P4 Xeon

[Peter B Van Campen]

Dear List,

I run this kernel on a dual P-III = 2.4.18-64GB-SMP
When I start a SETI (numerical intensive analysis pgm) one from each of two 
seperate subdirs the work is quite evenly distributed across the 2 CPUs. When 
I add a third SETI process in a third subdir the additional work seems to be 
evenly spread over each processor as well. It seems counter-intuitive but it 
cranks out more SETI units ever so slightly . I have no explaination for 
that.

PeterB

Re: Process binding on Dual P4 Xeon

[Simon Oliver]

John Alvord wrote:
> 
> The usual explanation is that the monitoring program and the terminal
> program (or X-Windows) are both interactive and bump the compute
> intensive tasks off... when they return they return randomly to the
> free CPU. A bit of hesenberg uncertainity if you know atomic
> physics...

I can understand the processor switching but why the 50/50 or even
stranger 25/75 split?  But how can a single threaded process be split
accross more that one CPU and why the odd ratio?  It's as if the chipset
were deciding where to run the jobs, not the kernel.

-- 
  Simon Oliver