On 8/15/23, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 15 Aug 2023 at 07:12, kernel test robot <oliver.sang@xxxxxxxxx> > wrote: >> >> kernel test robot noticed a 6.3% improvement of stress-ng.zero.ops_per_sec >> on: > > WTF? That's ridiculous. Why would that even test new_inode() at all? > And why would it make any difference anyway to prefetch a new inode? > The 'zero' test claims to just read /dev/zero in a loop... > > [ Goes looking ] > Ye man, I was puzzled myself but just figured it out and was about to respond ;) # bpftrace -e 'kprobe:new_inode { @[kstack()] = count(); }' Attaching 1 probe... @[ new_inode+1 shmem_get_inode+137 __shmem_file_setup+195 shmem_zero_setup+46 mmap_region+1937 do_mmap+956 vm_mmap_pgoff+224 do_syscall_64+46 entry_SYSCALL_64_after_hwframe+115 ]: 2689570 the bench is doing this *A LOT* and this looks so fishy, for the bench itself and the kernel doing it, but I'm not going to dig into any of that. >> 39.35 -0.3 39.09 >> perf-profile.calltrace.cycles-pp.inode_sb_list_add.new_inode.shmem_get_inode.__shmem_file_setup.shmem_zero_setup > > Ahh. It also does the mmap side, and the shared case ends up always > creating a new inode. > > And while the test only tests *reading* and the mmap is read-only, the > /dev/zero file descriptor was opened for writing too, for a different > part of a test. > > So even though the mapping is never written to, MAYWRITE is set, and > so the /dev/zero mapping is done as a shared memory mapping and we > can't do it as just a private one. > > That's kind of stupid and looks unintentional, but whatever. > > End result: that benchmark ends up being at least partly (and a fairly > noticeable part) a shmem setup benchmark, for no actual good reason. > > Oh well. I certainly don't mind the removal apparently then also > helping some odd benchmark case, but I don't think this translates to > anything real. Very random. > > Linus > -- Mateusz Guzik <mjguzik gmail.com>
![]() |