Re: HT schedulers' performance on single HT processor

[Nathan Fredrickson]

On Sun, 2003-12-14 at 15:35, Adam Kropelin wrote:
> On Sun, Dec 14, 2003 at 02:49:24PM -0500, Nathan Fredrickson wrote:
> > Same table as above normalized to the j=1 uniproc case to make
> > comparisons easier.  Lower is still better.
> > 
> >              j =  1     2     3     4     8
> > 1phys (uniproc)  1.00  1.00  1.00  1.00  1.00
> > 1phys w/HT       1.02  1.02  0.87  0.87  0.87
> > 1phys w/HT (w26) 1.02  1.02  0.87  0.87  0.88
> > 1phys w/HT (C1)  1.03  1.02  0.88  0.88  0.88
> > 2phys            1.00  1.00  0.53  0.53  0.53
>   ^^^^^                  ^^^^
> 
> Ummm...
> 
> This is mighty suspicious. With -j2 did you check to see that there
> were indeed two parallel gcc's running? Since -test6 I've found that 
> -j2 only results in a single gcc instance. I've seen this on both an
> old hacked-up RH 7.3 installation and a brand new RH 9 + updates
> installation.

I just checked and you're right, the number of compilers that actually
run is j-1, for all j>1.  I assume this is a problem with the parallel
build process, but it does not invalidate these results for comparing
the scheduler performance with different patches.
> 
> > This suggests that j should be set to at least the number of logical
> > processors + 1.
> 
> Since -test6 I've found this to be the case for kernel builds, yes. But
> I don't think it has anything to do with the scheduler or HT vs SMP
> platforms.

The 1-3% performance loss when HT is enabled for -j1 is still very real.

Nathan



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