From owner-freebsd-current Sun Apr 15 23:16:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9A57F37B423 for ; Sun, 15 Apr 2001 23:16:21 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3G6GI973782; Sun, 15 Apr 2001 23:16:18 -0700 (PDT) (envelope-from dillon) Date: Sun, 15 Apr 2001 23:16:18 -0700 (PDT) From: Matt Dillon Message-Id: <200104160616.f3G6GI973782@earth.backplane.com> To: "Justin T. Gibbs" Cc: Doug Barton , "'current@freebsd.org'" Subject: Re: FW: Filesystem gets a huge performance boost References: <200104160259.f3G2xqs06321@aslan.scsiguy.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message