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