Re: Industry db benchmark result on recent 2.6 kernels

From: Paul Jackson
Date: Fri Apr 01 2005 - 04:32:58 EST


> It has to be made sure that H1+H2+H3 != H4+H5+H6,

Yeah - if you start trying to think about the general case here, the
combinations tend to explode on one.

I'm thinking we get off easy, because:

1) Specific arch's can apply specific short cuts.

My intuition was that any specific architecture, when it
got down to specifics, could find enough ways to cheat
so that it could get results quickly, that easily fit
in a single 'distance' word, which results were 'close
enough.'

2) The bigger the system, the more uniform its core hardware.

At least SGI's big iron systems are usually pretty
uniform in the hardware that matters here. We might mix
two cpu speeds, or a couple of memory sizes. Not much
more, at least that I know of. A 1024 NUMA cobbled
together from a wide variety of parts would be a very
strange beast indeed.

3) Approximate results (aliasing at the edges) are ok.

If the SN2 arch code ends up telling the cache latency
initialization code that two cpus on opposite sides of
a 1024 cpu system are the same distance as another such
pair, even though they aren't exactly the same distance,
does anyone care? Not I.

So I think we've got plenty of opportunity to special case arch's,
plenty of headroom, and plenty of latitude to bend not break if we do
start to push the limits.

Think of that 64 bits as if it was floating point, not int.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@xxxxxxxxxxxx> 1.650.933.1373, 1.925.600.0401
-
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/