:>    There's no downside, really.
:It just seems inelegant to have a system that, on paper, is
:so inefficient.  Can't we do better?

    I don't consider it inefficient.  Sure, if you look at this one aspect
    of the caching taken out of context it may appear to be inefficient, 
    but if you look at the whole enchilada the memory issue is nothing
    more then a minor footnote - not worth the effort of worrying about.

    It's far more important to cache the right things then it is to be
    memory-efficient.  If you think about it, a 'memory inefficient'
    cache is an oxymoron -- the cache isn't actually taking memory
    away from anyone else, so the worst effect that you will see is,
    say, 60MB of cache acting as if it were 55MB of cache.  A difference
    like that is nothing compared to choosing the right things to cache
    in the first place.

    An even greater issue.. greater then everything else put together, is
    the fact that our current VFS/BIO subsystem is far too complex.  A
    staggering number of bugs have been found and fixed, and there are
    probably still more yet to be found in the original code.  If I could
    trade all of those bugs for a slightly less memory efficient subsystem
    I would do it in a heartbeep :-)  Efficiency is no good if the subsystem
    isn't reliable.  Far too much attention is being paid to making things
    fast and (theoretically) efficient and far too little is being paid
    to reliability these days.  For example, all this work on a preemptive
    kernel is just insane.  Our entire kernel is built on the concept of
    not being preemptable except by interrupts.  We virtually guarentee
    years of instability and bugs leaking out of the woodwork by trying to
    make it preemptable, and the performance gain we get for that pain
    is going to be zilch.  Nada.  Nothing.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to