Re: 2.6.0-test4 shocking (HT) benchmarking (wrong logic./phys. HT CPU distinction?)

[Andrew Theurer]

On Tuesday 26 August 2003 14:12, Richard B. Johnson wrote:
> On Tue, 26 Aug 2003, Andy Isaacson wrote:
> > On Tue, Aug 26, 2003, max@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> > > in our fine physics group we recently bought a DUAL XEON P4 2666MHz,
> > > 2GB, with
> > > hyper-threading support and I had the honour of making the thing work.
> > > In the
> > > process I also did some benchmarking using two different kernels (stock
> > > SuSE-8.2-Pro 2.4.20-64GB-SMP, and the latest and greatest vanilla
> > > 2.6.0-test4). I benchmarked

Chances are -neither- of these kernels have HT enhancements for the scheduler.  
I am positive the 260test kernels do not have shared runqueues for HT 
siblings and the scheduler does not make use of the cpu_sibling_map.  Test 
make -j2 with HT disabled, and I bet you get better results than make -j2 
with HT enabled....

> P.S. HT References I found online have not compared HT between 2.4 and 2.6, 
> but they all assume improvements in 2.6.
> http://www.linuxworld.com/story/33885.htm

This article is incorrect.  The scheduler changes did not make it in to 2.5.32

> http://www-106.ibm.com/developerworks/linux/library/l-htl/

This article discusses the changes needed, but does not state that the changes 
are in the 2.5 kernel.

This is still a problem, even the "What to Expect From 2.6" is incorrect:
http://ftp.kernel.org/pub/linux/kernel/people/davej/misc/post-halloween-2.5.txt

Ingo's latest patch that fixes this is here:
http://people.redhat.com/mingo/O(1)-scheduler/sched-2.5.68-B2

And here for 2.4:
http://people.redhat.com/mingo/O(1)-scheduler/sched-HT-2.4.21-rc7-ac1-A1

Not sure why the FFT results are so much lower on 2.6, but I'm not sure sure 
it has anything to do with HT, maybe something else?  Can you try turning off 
HT and see what happens?

-Andrew Theurer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/