Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Feb 2002 17:15:08 -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:  <200202230115.g1N1F8M32679@apollo.backplane.com>
References:   <XFMail.020222201138.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

:On 22-Feb-02 Julian Elischer wrote:
:> OK here is my suggestion:
:> 
:> We add extra code under DIAGNOSTIC
:> the code does:
:
:Hang on.  The only reason this stuff is under DIAGNOSTIC is because of the
:performance.  If you put it under DIAGNOSTIC, please don't make it all gross
:and complicated, just leave it simple. If you want to optimize it put it under
:INVARIANTS.  Geez.
:
:Secondly, did anyone try pushing down Giant into crfree() for the case where we
:actually call free() and see if that helped the performacne?  Giant thrashing
:is probably what the big problem was.  In almost every case you would be
:just decrementing the refcount using the same logic used to justify this
:caching scheme.
:
:Oh well, for my testing I'll just stick this all back under INVARIANTS and push
:down Giant in my branch.  Much cleaner and useful to me personally.  If no one
:else wants to test this (td_ucred) code more power to them.
:
:-- 
:
:John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
:"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

    With Julian's caching code crfree() is taken out of the loop.  Poof, gone.
    Becomes a non-issue.

    For what it is worth, I agree with you in regards to the weird extra field
    switching Julian is doing...  we do not need to optimize the DIAGNOSTIC case.
    DIAGNOSTIC is just assumed to be universally non-optimal.  But, remember,
    I'm the guy who just wants to scrap the ucred NULLing completely.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

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?200202230115.g1N1F8M32679>