Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 May 1997 02:17:39 -0700 (PDT)
From:      Poul-Henning Kamp <phk@FreeBSD.ORG>
To:        CVS-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Subject:   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:  <199705040917.CAA29144@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
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



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