NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/56329: nvme(4) takes long time to umount



The following reply was made to PR kern/56329; it has been noted by GNATS.

From: Christos Zoulas <christos%zoulas.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, paul%whooppee.com@localhost
Subject: Re: kern/56329: nvme(4) takes long time to umount
Date: Mon, 25 Apr 2022 11:07:38 -0400

 But should't be something applying backpressure so that the number of vnodes=
  to be recycled is kept reasonably sized?
 
 christos
 
 > On Apr 25, 2022, at 10:05 AM, J. Hannken-Illjes <hannken%mailbox.org@localhost> wrot=
 e:
 >=20
 > =EF=BB=BFThe following reply was made to PR kern/56329; it has been noted b=
 y GNATS.
 >=20
 > From: "J. Hannken-Illjes" <hannken%mailbox.org@localhost>
 > To: NetBSD GNATS <gnats-bugs%netbsd.org@localhost>
 > Cc:=20
 > Subject: Re: kern/56329: nvme(4) takes long time to umount
 > Date: Mon, 25 Apr 2022 16:02:40 +0200
 >=20
 > With help from Paul Goyette I'm able to reproduce the behaviour here.
 >=20
 > - It is not related to nvme, it depends on the number of cached
 >   vnodes, 3456591 in the last run taking ~7 seconds.
 >=20
 > - With 64GByte memory my test machine takes ~6 seconds to unmount
 >   a file system with 3332133 cached vnodes with "ld at virtio".
 >=20
 > - This time to unmount didn't change in the last 7 years, testing
 >   kernels from October 2014, 2015 ... until now it always took 5 +- 1
 >   seconds to unmount.
 >=20
 > - Latest run took 5.864 seconds, 1.311 were spent in cache_purgevfs(),
 >   0.290 in VFS_SYNC() and 4.263 in vflush().
 >=20
 > To me this doesn't look like a regression and recycling ~570000 vnodes
 > per second looks ok.
 >=20
 > --
 > J. Hannken-Illjes - hannken%mailbox.org@localhost
 >=20
 


Home | Main Index | Thread Index | Old Index