On Wed, Sep 23, 2020 at 10:46:07AM +0000, Mateusz Guzik wrote:
> Author: mjg
> Date: Wed Sep 23 10:46:07 2020
> New Revision: 366071
> URL: https://svnweb.freebsd.org/changeset/base/366071
> 
> Log:
>   cache: drop the force flag from purgevfs
>   
>   The optional scan is wasteful, thus it is removed altogether from unmount.
>   
>   Callers which always want it anyway remain unaffected.
> 
> Modified:
>   head/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c
>   head/sys/kern/vfs_cache.c
>   head/sys/kern/vfs_mount.c
>   head/sys/kern/vfs_mountroot.c
>   head/sys/sys/vnode.h
> 
> Modified: head/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c
> ==============================================================================
> --- head/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c       Wed Sep 
> 23 10:44:49 2020        (r366070)
> +++ head/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c       Wed Sep 
> 23 10:46:07 2020        (r366071)
> @@ -1532,7 +1532,7 @@ zfsvfs_teardown(zfsvfs_t *zfsvfs, boolean_t unmounting
>                * 'z_parent' is self referential for non-snapshots.
>                */
>  #ifdef FREEBSD_NAMECACHE
> -             cache_purgevfs(zfsvfs->z_parent->z_vfs, true);
> +             cache_purgevfs(zfsvfs->z_parent->z_vfs);
>  #endif
>       }
>  
> 
> Modified: head/sys/kern/vfs_cache.c
> ==============================================================================
> --- head/sys/kern/vfs_cache.c Wed Sep 23 10:44:49 2020        (r366070)
> +++ head/sys/kern/vfs_cache.c Wed Sep 23 10:46:07 2020        (r366071)
> @@ -295,9 +295,6 @@ static u_long __exclusive_cache_line      numcache;/* 
> numbe
>  u_int ncsizefactor = 2;
>  SYSCTL_UINT(_vfs, OID_AUTO, ncsizefactor, CTLFLAG_RW, &ncsizefactor, 0,
>      "Size factor for namecache");
> -static u_int __read_mostly   ncpurgeminvnodes;
> -SYSCTL_UINT(_vfs, OID_AUTO, ncpurgeminvnodes, CTLFLAG_RW, &ncpurgeminvnodes, 
> 0,
> -    "Number of vnodes below which purgevfs ignores the request");
>  static u_int __read_mostly   ncsize; /* the size as computed on creation or 
> resizing */
>  
>  struct nchstats      nchstats;               /* cache effectiveness 
> statistics */
> @@ -2142,7 +2139,6 @@ nchinit(void *dummy __unused)
>           M_WAITOK | M_ZERO);
>       for (i = 0; i < numvnodelocks; i++)
>               mtx_init(&vnodelocks[i], "ncvn", NULL, MTX_DUPOK | MTX_RECURSE);
> -     ncpurgeminvnodes = numbucketlocks * 2;
>  
>       neglists = malloc(sizeof(*neglists) * numneglists, M_VFSCACHE,
>           M_WAITOK | M_ZERO);
> @@ -2369,14 +2365,11 @@ cache_rename(struct vnode *fdvp, struct vnode *fvp, st
>   * Flush all entries referencing a particular filesystem.
>   */
>  void
> -cache_purgevfs(struct mount *mp, bool force)
> +cache_purgevfs(struct mount *mp)
>  {
>       struct vnode *vp, *mvp;
>  
>       SDT_PROBE1(vfs, namecache, purgevfs, done, mp);
> -     if (!force && mp->mnt_nvnodelistsize <= ncpurgeminvnodes)
> -             return;
> -
>       /*
>        * Somewhat wasteful iteration over all vnodes. Would be better to
>        * support filtering and avoid the interlock to begin with.
> 
> Modified: head/sys/kern/vfs_mount.c
> ==============================================================================
> --- head/sys/kern/vfs_mount.c Wed Sep 23 10:44:49 2020        (r366070)
> +++ head/sys/kern/vfs_mount.c Wed Sep 23 10:46:07 2020        (r366071)
> @@ -1808,7 +1808,6 @@ dounmount(struct mount *mp, int flags, struct thread *
>       mp->mnt_flag &= ~MNT_ASYNC;
>       mp->mnt_kern_flag &= ~MNTK_ASYNC;
>       MNT_IUNLOCK(mp);
> -     cache_purgevfs(mp, false); /* remove cache entries for this file sys */
>       vfs_deallocate_syncvnode(mp);
>       error = VFS_UNMOUNT(mp, flags);
Is there any checker for debugging kernels, that no cache entries are
left after unmount ?

>       vn_finished_write(mp);
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to