Re: [patch 2.6.14-rc4] i386: spinlock optimization

[Ingo Molnar]

* Chuck Ebbert <76306.1226@xxxxxxxxxxxxxx> wrote:

> Parent CPU 1, child CPU 0, using old code for lock
> CPU clocks: 2066947815
> Parent CPU 1, child CPU 0, using new code for lock
> CPU clocks: 2818166922

> Parent CPU 1, child CPU 0, using old code for lock
> CPU clocks: 5635093038
> Parent CPU 1, child CPU 0, using new code for lock
> CPU clocks: 5250078921

your numbers show that for the first box, there's a 36% net slowdown 
resulting from the new code. On the other (older) box, there's a 7% 
speedup from the new code.

i ran the code on two newer boxes, 2.4 and 3.4 GHz Xeons, on two sibling 
CPUs sharing the same physical CPU and on two different CPUs as well:

HT non-siblings [Xeon 2.40GHz], 1% slowdown:

 Parent CPU 2, child CPU 0, using old code for lock
 CPU clocks: 6712771070
 Parent CPU 2, child CPU 0, using new code for lock
 CPU clocks: 6787556068

HT siblings [Xeon 2.40GHz], 14% speedup:

 Parent CPU 1, child CPU 0, using old code for lock
 CPU clocks: 3587124593
 Parent CPU 1, child CPU 0, using new code for lock
 CPU clocks: 3079647206

HT non-siblings [Xeon 3.40GHz], 3% speedup:

 Parent CPU 2, child CPU 0, using old code for lock
 CPU clocks: 8486900988
 Parent CPU 2, child CPU 0, using new code for lock
 CPU clocks: 8255818784

HT siblings [Xeon 3.40GHz], 1% slowdown:

 Parent CPU 3, child CPU 0, using old code for lock
 CPU clocks: 3684195488
 Parent CPU 3, child CPU 0, using new code for lock
 CPU clocks: 3739797320

but given that the code is a drastic slowdown on older boxes (and 
results in higher memory bus traffic, which may slow down other CPUs 
too, which effect isnt measured here), i dont think we should apply the 
patch, just yet - up until the point it becomes a clear winner on new 
CPUs.

(in fact the ping-pong effect should be worse if more than 2 CPUs 
contend for the spinlock.)

could someone run the tests on a dual-core box too?

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