lkml.org 
[lkml]   [2000]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Auto-Adaptive scheduler - Final chapter ( the numbers ) ...
    Date
    From
    : 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/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:4.497 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site