Re: File trees: the deeper, the weirder

It's possible to allow intermediate directory vnodes to be reclaimed by
adjusting cache_leaf_check(), etc, but doing so will cause the kernel
getcwd to fail a lot more often. This is, in fact, how reclamation worked
before I added cache_leaf_check(). That work was never completed in
FreeBSD (I finished it in DragonFly). It probably wouldn't hurt a
whole lot to nerf it, since I don't think there is anyone in FreeBSDland
really interested in converting the namecache from a vnode-centric
topology to an independant namecache-centric topology like we have
in DragonFly.

Still, I wouldn't remove it entirely. Directory vnodes have a tendency
to go by the wayside during scans (tar, find, etc) and get recycled far
earlier then they otherwise should.

The bigger issue with regards to vnode recycling is the VM page cache.
Vnodes with cached VM pages do not usually get recycled and the vnode
system relies on the VM system's page recycling to eventually free up
all the VM pages associated with a vnode and make it recyclable. But
on modern systems with tons of physical memory accessing lots of tiny
files it is possible to have plenty of free memory but still have too
many unrecyclable vnodes due to the presence of cached VM pages for
those vnodes.

There is code in vlrureclaim() that tries to solve this problem by
calculating a 'trigger' point -- all VM objects with less then the
trigger point number of cached VM pages are considered recyclable.
See line 566 in vfs_subr.c in FreeBSD HEAD. This calculation is
fairly primitive in FreeBSD. There is a more sophisticated version
in DragonFly which scales the trigger point up when the vnode recycler
detects that it is having problems. You should look at it. Line 501
in kern/vfs_mount.c in DragonFly HEAD is a good starting point.

-Matt

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Packet loss every 30.999 seconds
    ... turns out there's an actual problem for it to fix. ... It's the syncer that is causing the problem, and it runs every 31 seconds. ... stupid in how it works - it loops through all of the vnodes on each ffs ... typically 50000-100000) and combined with kernel threads of FreeBSD 5, ...
    (freebsd-net)
  • Re: Packet loss every 30.999 seconds
    ... turns out there's an actual problem for it to fix. ... It's the syncer that is causing the problem, and it runs every 31 seconds. ... stupid in how it works - it loops through all of the vnodes on each ffs ... typically 50000-100000) and combined with kernel threads of FreeBSD 5, ...
    (freebsd-stable)
  • Re: Packet loss every 30.999 seconds
    ... FreeBSD used to have some code that would cause vnodes with no cached ... Pave the road of life with opportunities. ...
    (freebsd-net)
  • Re: Packet loss every 30.999 seconds
    ... FreeBSD used to have some code that would cause vnodes with no cached ... Pave the road of life with opportunities. ...
    (freebsd-stable)