| Date | Mon, 24 Feb 2003 16:23:09 -0800 | From | Larry McVoy <> | Subject | Re: Minutes from Feb 21 LSE Call |
| |
> 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/
|