: 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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:20 EST