Re: namecache stage-2 patch for testing

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Oh, note that I have two debugging printf()'s still in there.  Just
    remove them if the console gets too noisy.

:	By the way, what kind of performance improvements are we looking
:	at with this new code (including stage-3) in place?

    With stage-3 lookup() and namei() will be rewritten.  I wasn't planning
    on adding any performance improvements in stage-3 but we will get some
    parallelism / stall situations fixed for free by not having to
    exclusively lock directory vnodes.  The race-to-root issue will be gone.

    There are a number of potential optimizations that can be made as well.
    In a later stage we could easily add a ucred cache pointer to the
    namecache structure and avoid all VOP locking and access operations for
    procs with matching ucreds when traversing a path.  Or something like
    that.  That would about double namei()'s performance.


:> +int	textvp_fullpath (struct proc *p, char **retbuf, char **retfreebuf);
:
:	Also, just a little snooping around, I think the
:	textvp_fullpath() function can made a little generic so it is
:	applicable to other cases.  I have a patch lurking around for
:	this somewhere, I will e-mail it to you by Friday.
:
:	I haven't gone through the whole patch in detail, as I am
:	feeling kinda sleepy. ;-)
:
:	Regards,
:
:-- 
:Hiten Pandya
:hmp@xxxxxxxxxxxxx

    In stage-3 textvp_fullpath() and __getcwd() will be rewritten to simply
    traverse namecache structures.  They could probably be collapsed at that
    point because the namecache components will still exist even if the
    underlying file is deleted in the textvp case.  But these functions are
    not called all that often so there is no performance gain.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>