> The changes are getting measured. By and large if it's slower on UP
> it's rejected.
Suppose I have an application which has a working set which just exactly
fits in the I+D caches, including the related OS stuff.
Someone makes some change to the OS and the benchmark for that change is
smaller than the I+D caches but the change increased the I+D cache space
needed.
The benchmark will not show any slowdown, correct?
My application no longer fits and will suffer, correct?
The point is that if you are putting SMP changes into the system, you
have to be held to a higher standard for measurement given the past
track record of SMP changes increasing code length and cache footprints.
So "measuring" doesn't mean "it's not slower on XYZ microbenchmark".
It means "under the following work loads the cache misses went down or
stayed the same for before and after tests".
And if you said that all changes should be held to this standard, not
just scaling changes, I'd agree with you. But scaling changes are the
"bad guy" in my mind, they are not to be trusted, so they should be held
to this standard first. If we can get everyone to step up to this bat,
that's all to the good.
-- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 22:00:24 EST