Messages in this thread | | | Subject | Re: Auto-Adaptive scheduler - Final chapter ( the numbers ) ... | Date | Thu, 27 Jan 2000 22:05:25 -0800 | From | Larry McVoy <> |
| |
: However, I think that Davide knows something about caches as well.
Hmm. With no offense intended, that's certainly not at all clear from this discussion. What is it that makes you think that?
: Cache problems are important, but so is effective code and good : algorithms. Of course, it's a pretty secure stance - can't add any new : things because they will increase cache misses. But an extra kilobyte : (probably less) isn't going to matter.
The hell it doesn't. If I have an application that manages to the working set in the on chip cache, and you increase the kernel's use of that on chip cache by 1K, you just blew the application out of the cache.
Quick - without looking it up, how many cycles to do a load from your average on chip cache and how many to do a load from level 2 cache?
Whether you understand it or not, one of Linux' strengths - one of the main reasons that it does better than many other systems - is that it is small. The cache footprint required to do something in Linux is enough smaller than other OSes that many operations fit in the L1 cache that on other OSes spill out of the L1 cache. This makes things go much more slowly (unless you're on an HP with that nifty 1.5MB L1 cache 1 cycle away, yum, yum).
If you were to bloat up the frequently traversed code paths in Linux such that you no longer fit in the L1 cache, what's left? What exactly is it that Linux has that is better than Solaris or HPUX or IRIX or AIX? I've been through much of those operating systems and I can tell you that there is basically very litle difference between the approach that Linux has and the approach that any of the other ones have, other than a passionate desire to stay small while still offering the functionality.
More code does not make you go faster in almost all cases.
: Actually, : as Davide's patch doesn't need to access every task in the RQ, the chance : of a cache miss is actually lower
I'm not sure that "the chance" of anything is relevent here, what we clearly need is data. The cycle counters and cache miss counters of before and after.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |