Re: [linux-next:master] [loop] d908729e74: stress-ng.umount.ops_per_sec 100.0% regression
Tetsuo Handa <[email protected]> Wed, 15 Jul 2026 23:25:38 +0900
| Newsgroups | dev.linux.lists.oe-lkp,org.kernel.vger.linux-block,org.kernel.vger.linux-fsdevel |
|---|---|
| Message-ID | <[email protected]> |
On 2026/07/15 22:55, kernel test robot wrote: > > hi, Tetsuo Handa, > > this report is just FYI. > we understand d908729e74 is an experimental patch, and it seems there are lots > of print while running stress-ng.umount tests (one dmesg is attached) > > [ 59.370110][T10457] do_umount: task=stress-ng-umoun[10457] propagate_mount_busy()!=0 > [ 59.394831][T10476] do_umount: task=stress-ng-umoun[10476] propagate_mount_busy()!=0 > [ 59.404989][T10477] do_umount: task=stress-ng-umoun[10477] propagate_mount_busy()!=0 > [ 59.414578][T10473] do_umount: task=stress-ng-umoun[10473] propagate_mount_busy()!=0 > [ 59.423911][T10460] do_umount: task=stress-ng-umoun[10460] propagate_mount_busy()!=0 > > .... > > > so the very slow performance is expected? Since printk() is a slow operation, stressing umount() operation that fail with -EBUSY can cause significantly slow performance. Can you try without fs/namespace.c changes?