Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Feb 2002 14:04:57 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG
Subject:   Re: RE: that INVARIANT/ucred freeing stuff.
Message-ID:  <200202212204.g1LM4vQ09988@apollo.backplane.com>
References:   <XFMail.020221095241.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
    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 <sarcastic> 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.
:
:</sarcasm>
:
: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 <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202212204.g1LM4vQ09988>