Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> wrote:
> The numbers are not that bad, but definitely not as good as we saw
> on some other platforms.
Well, this machine is definitely designed to hold up under high
concurrency. As I understand it, each core is the memory manager
for two 4GB DIMMs, with two channels to them, each with two buffers.
The way the cores are connected, a core never needs to go through
more than one other core to get to memory not directly managed, and
that uses "snoop" technology which hands the cached data right over
from one core to the other when possible, rather than making the
core which now owns the cache line pull it from RAM. It seems the
2.6.32 kernel is able to manage that technology in a reasonable
fashion.
At first I was surprised to see performance top out on the update
tests between 80 and 96 clients. But then, that lands almost
exactly where my old reliable ((2 * core count) + effective spindle
count) would predict. The SELECT only tests peaked at 64 clients,
but those were fully cached, so effective spindle count was zero,
again fitting the formula. So these optimizations seem to me to
break down the barriers which had previously capped the number of
clients which could be handled, letting them peak at their "natural"
levels.
> But its possible that they may improve in percentage terms with
> even more number of clients on this box.
I think so; I think this box is just so scalable that at 128
clients we were just barely getting past the "knee" in the
performance graphs to where these patches help most.
-Kevin