:>    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.
:This is like saying that there is nothing to be gained by making better
:use of available cache memory.  I don't care that the cache is dynamic
:and caches the right things when the cache is effectively made so small
:that it doesn't cache my working set.  Even with VMIO turned on for
:directories, Linux kicks our ass in caching meta-data unless you have
:a lot of memory.  That sucks.

    It is not implying that at all.  There is no black and white here.
    This is a case where spending a huge amount of time and complexity
    to get the efficiency down to the Nth degree is nothing but a waste
    of time.  What matters is what the user sees, what performance
    the application gets, and how many bugs you introduce when optimizing
    something that might not need optimizing.

    And in regards to Linux... you can't possibly be implying that 
    performance differences between linux and FreeBSD are due to whether
    we spend 4K or 512 bytes caching a directory block.  The issue has
    nothing to do with small-directory memory efficiency.


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

Reply via email to