From owner-freebsd-arch Thu Feb 21 14: 5: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id ADE5937B402; Thu, 21 Feb 2002 14:04:57 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1LM4vQ09988; Thu, 21 Feb 2002 14:04:57 -0800 (PST) (envelope-from dillon) Date: Thu, 21 Feb 2002 14:04:57 -0800 (PST) From: Matthew Dillon Message-Id: <200202212204.g1LM4vQ09988@apollo.backplane.com> To: John Baldwin Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: RE: that INVARIANT/ucred freeing stuff. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG We learned a lesson with DIAGNOSTIC. You are repeating the same mistakes DIAGNOSTIC had which resulted in DIAGNOSTIC becoming essentially unusable. INVARIANTS != DIAGNOSTIC. If you want to resurrect DIAGNOSTIC you are welcome to throw this ucred-clearing code under that option. INVARIANTS is not supposed to change algorithms or optimizations wholesale. It is simply supposed to add additional sanity checks to existing algorithms and optimizations. So when the decision was made to implement td_ucred as an optimization, that means that is what we need to use. We should not go lobotomizing it for INVARIANTS. It's that simple. It is nothing even close to the absurdness of removing KASSERT for INVARIANTS that you are trying to contrast it against. What I recommend you do, John, is to add KASSERT()s at a few critical points in the code to assert that td_ucred is not being used out of context. We ... meaning Julian and myself mainly, see absolutely no point in lobotomizing an optimization that has such a huge effect on performance just because INVARIANTS is turned on. That is not the purpose of INVARIANTS. We want that code *GONE*. We would like you to acquiesce to this request. -Matt :Well, benchmarking debugging code usually isn't a very useful exercise. Why :not go for some more optimizations and change KASSSERT() to not do anything for :INVARIANTS either? That should add back in some performance as well. : : : :Seriously, getting Giant to do the free is probably biting you and doesn't need :to happen 99% of the time. You can push down Giant into crfree() around the :call to free() and see if that helps. Who needs debugging anyway, right? We :should all just be staring at the code and "seeing" bugs. : :> julian : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message