Re: [quad core results] BFS vs. mainline scheduler benchmarks and measurements

[Markus Tornqvist]

Let's test gmane's followup feature ;)

Ingo Molnar <mingo <at> elte.hu> writes:

> > Please Cc me as I'm not a subscriber.
> > >  kernel build performance on quad:
> > >     http://redhat.com/~mingo/misc/bfs-vs-tip-kbuild-quad.jpg
> > [...]
> > >
> > >It shows similar curves and behavior to the 8-core results i posted 
> > >- BFS is slower than mainline in virtually every measurement. The 
> > >ratios are different for different parts of the graphs - but the 
> > >trend is similar.
> > 
> > Dude, not cool.
> > 
> > 1. Quad HT is not the same as a 4-core desktop, you're doing it with 8 cores
> 
> No, it's 4 cores. HyperThreading adds two 'siblings' per core, which 
> are not 'cores'.

Like Serge Belyshev says in
http://article.gmane.org/gmane.linux.kernel/886881
and Con thanks you inthe FAQ for confiming it:
"h/w threads" - My Sempron II X4 lists four of those, and it seems
to be a common setup.
 
> > 2. You just proved BFS is better on the job_count == core_count case, as BFS
> >    says it is, if you look at the graph
> 
> I pointed that out too. I think the graphs speak for themselves:
> 
>      http://redhat.com/~mingo/misc/bfs-vs-tip-kbuild-quad.jpg
>      http://redhat.com/~mingo/misc/bfs-vs-tip-kbuild.jpg

Those are in alignment with the FAQ, for the hardware threads.

Mr Belyshev's benchmarks are closer to a common desktop and they rock
over CFS.

That's also something that IMO "we" forgot here: it doesn't really matter!

BFS is not up for merging, it feels way better than CFS on the desktop
and it does not scale.

This thread can be about improving CFS, I do not care personally, and
will stay out of that discussion.

> There's bfs-209 out there today. These tests take 8+ hours to 
> complete and validate. I'll re-test BFS in the future too, and as i 
> said it in the first mail i'll test it on a .31 base as well once 
> BFS has been ported to it:

Apropos your tests, under which circumstances would I have a million
piped messages on my desktop?

Would you care to comment on the relevance of your other tests from
a desktop point of view?

Fortunately you got help from the community as posted on the list.

> > Also, you said on http://article.gmane.org/gmane.linux.kernel/886319
> > "I also tried to configure the kernel in a BFS friendly way, i used 
> > HZ=1000 as recommended, turned off all debug options, etc. The 
> > kernel config i used can be found here:
> > http://redhat.com/~mingo/misc/config
> > "
> > 
> > Quickly looking at the conf you have
> > CONFIG_HZ_250=y
> > CONFIG_PREEMPT_NONE=y
> > # CONFIG_PREEMPT_VOLUNTARY is not set
> > # CONFIG_PREEMPT is not set
> 
> Indeed. HZ does not seem to matter according to what i see in my 
> measurements. Can you measure such sensitivity?

Hardly the point - You said one thing and got caught with something else,
which doesn't give a credible image.

Can I measure it? IANAKH, and I think there are people more passionate
here to run benchmark scripts and endless analyses.

All I can "measure" is that my desktop experience isn't stuttery and jittery
with basic stuff like scrolling over Firefox tabs with my mouse wheel
while watching pr0n.
 
> > CONFIG_ARCH_WANT_FRAME_POINTERS=y
> > CONFIG_FRAME_POINTER=y
> > 
> > And other DEBUG.
> 
> These are the defaults and they dont make a measurable difference to 
> these results. What other debug options do you mean and do they make 
> a difference?

Don't care as long as your kernel comparisons truly were with equivalent
settings to each other.

KÃszÃnÃm.

-- 
mjt


--
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/