Re: Minutes from Feb 21 LSE Call

[Larry McVoy <lm@bitmover.com>]

> 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