Strange scheduling behavoir in SMP

[pwalt en onthenet.com.au]

This is a different problem from the run queue one. 

The current scheduler (2.3) "less than optimal" for SMP. If you want to test,
you'll need a 2.2.11+ kernel, the patch of Andrea's and any cache intensive
program. Note that I'm referring to current 2.3.40 behaviour here. I'm not sure
if the current 2.2.14/15 still exhibits this behaviour, but 2.3.40 certainly
does.
       
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.14aa2/SMP-s
cheduler-2.2.11-E.gz

If I run "hog" on a dual Celeron without Andrea's patch it runs at around half
the speed that it does with the patch. 

Thats simply because WITH the patch CPU intensive tasks don't get kicked off
the CPU every time the scheduler decides to run a new task that only happens
when there's no idle CPU.

Without the patch the CPU hog is continually kicked from CPU to CPU.

Dual Celeron is probably the least hurt by this, on bigger SMP boxes
with more cache it's likely to be far worse.

100% is conservative, but the test program (attached) is also very much "worst
case".

This is a totally different issue from the current run-queue debate. Here there
are probably only ever 2 processes on the queue.

And yes, the code here is "benchmarkish", but it's pretty typical of
image processing, DSP and "seti en home" type tasks.

The comment WRT to the run queue debate was simply that there's a lot of heat
being generated about a 5% performance gain which is hard to measure when there
are currently other areas which are costing us a lot more.

 
Peter
----------------------------------
E-Mail: pwalt en onthenet.com.au
----------------------------------
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: hog.c
Type: application/octet-stream
Size: 634 bytes
Desc: no disponible
URL: <https://lists.srvr.mx/pipermail/ayuda/attachments/20000129/6006a2f6/attachment.obj>