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?