Date: Sun, 04 May 1997 11:33:33 +0200 From: Poul-Henning Kamp <phk@freebsd.org> Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/sys namei.h vnode.h src/sys/kern vfs_cache.c vfs_subr.c src/sys/nfs nfs_vnops.c Message-ID: <1254.862738413@critter> In-Reply-To: Your message of "Sun, 04 May 1997 02:17:39 PDT." <199705040917.CAA29144@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This change probably means that your machine will panic if it uses an
old LKM.
You have been warned. :-)
I'm very interested in high-quality measurements of the impact of this
change. In particular if you have numbers for big server applications,
news, http or otherwise.
In particular, keep an eye on, and report, the two sysctl variables
"debug.numvnodes" and "kern.maxvnodes", but be aware that the latter
is grossly incorrectly named.
You may want to tweak debug.ncnegfactor, which determines how many
negative namecache entries to keep around. It defaults to 16 which
means that 1/16th of the namecache is allowed to be used for negative
entries. Report your findings.
Poul-Henning
>phk 97/05/04 02:17:39
>
> Modified: sys/kern vfs_cache.c vfs_subr.c
> sys/nfs nfs_vnops.c
> sys/sys namei.h vnode.h
> Log:
> 1. Add a {pointer, v_id} pair to the vnode to store the reference to the
> ".." vnode. This is cheaper storagewise than keeping it in the
> namecache, and it makes more sense since it's a 1:1 mapping.
>
> 2. Also handle the case of "." more intelligently rather than stuff
> the namecache with pointless entries.
>
> 3. Add two lists to the vnode and hang namecache entries which go from
> or to this vnode. When cleaning a vnode, delete all namecache
> entries it invalidates.
>
> 4. Never reuse namecache enties, malloc new ones when we need it, free
> old ones when they die. No longer a hard limit on how many we can
> have.
>
> 5. Remove the upper limit on namelength of namecache entries.
>
> 6. Make a global list for negative namecache entries, limit their number
> to a sysctl'able (debug.ncnegfactor) fraction of the total namecache.
> Currently the default fraction is 1/16th. (Suggestions for better
> default wanted!)
>
> 7. Assign v_id correctly in the face of 32bit rollover.
>
> 8. Remove the LRU list for namecache entries, not needed. Remove the
> #ifdef NCH_STATISTICS stuff, it's not needed either.
>
> 9. Use the vnode freelist as a true LRU list, also for namecache accesses.
>
> 10. Reuse vnodes more aggresively but also more selectively, if we can't
> reuse, malloc a new one. There is no longer a hard limit on their
> number, they grow to the point where we don't reuse potentially
> usable vnodes. A vnode will not get recycled if still has pages in
> core or if it is the source of namecache entries (Yes, this does
> indeed work :-) "." and ".." are not namecache entries any longer...)
>
> 11. Do not overload the v_id field in namecache entries with whiteout
> information, use a char sized flags field instead, so we can get
> rid of the vpid and v_id fields from the namecache struct. Since
> we're linked to the vnodes and purged when they're cleaned, we don't
> have to check the v_id any more.
>
> 12. NFS knew about the limitation on name length in the namecache, it
> shouldn't and doesn't now.
>
> Bugs:
> The namecache statistics no longer includes the hits for ".."
> and "." hits.
>
> Performance impact:
> Generally in the +/- 0.5% for "normal" workstations, but
> I hope this will allow the system to be selftuning over a
> bigger range of "special" applications. The case where
> RAM is available but unused for cache because we don't have
> any vnodes should be gone.
>
> Future work:
> Straighten out the namecache statistics.
>
> "desiredvnodes" is still used to (bogusly ?) size hash
> tables in the filesystems.
>
> I have still to find a way to safely free unused vnodes
> back so their number can shrink when not needed.
>
> There is a few uses of the v_id field left in the filesystems,
> scheduled for demolition at a later time.
>
> Maybe a one slot cache for unused namecache entries should
> be implemented to decrease the malloc/free frequency.
>
> Revision Changes Path
> 1.25 +105 -107 src/sys/kern/vfs_cache.c
> 1.85 +53 -45 src/sys/kern/vfs_subr.c
> 1.47 +2 -3 src/sys/nfs/nfs_vnops.c
> 1.14 +6 -18 src/sys/sys/namei.h
> 1.44 +7 -2 src/sys/sys/vnode.h
--
Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox.
whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc.
Power and ignorance is a disgusting cocktail.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1254.862738413>