:
:> There's no downside, really.
:
:It just seems inelegant to have a system that, on paper, is
:so inefficient. Can't we do better?
:
:--
:Justin
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.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
