linux-kernel - Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGudoHGuf8JZJjMcs+aYPN7jH+q6Og2CNvSg1-qjJ8kH6SJbJg@mail.gmail.com>
Date: Thu, 27 Jun 2024 19:20:03 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, lkp@...el.com, 
	Linux Memory Management List <linux-mm@...ck.org>, Christian Brauner <brauner@...nel.org>, linux-kernel@...r.kernel.org, 
	ying.huang@...el.com, feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput
 -33.7% regression

On Thu, Jun 27, 2024 at 6:57 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Thu, 27 Jun 2024 at 09:32, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> >   getdent subtest:
> >       +4.1   lockref_put_return
> >       +5.7   lockref_get_not_dead
> >      +68.0   native_queued_spin_lock_slowpath
>
> For this getdents load, the main call chains that terminate in the
> queued spinlock case seem to be
>
> .lockref_get_not_dead.__legitimize_path.try_to_unlazy_next.lookup_fast
> .lockref_get_not_dead.__legitimize_path.try_to_unlazy.lookup_fast
> .lockref_get_not_dead.__legitimize_path.try_to_unlazy.link_path_walk
> .dput.terminate_walk.path_openat.do_filp_open
>
> which is interesting because I would have expected the readdir() code
> itself to show up.
>
> But the proc_pident_readdir profiles have all gone down, presumably
> because there's just much fewer of them. That part shows no spinlock
> in the profile at all.
>
> WTH is that benchmark doing? The only readdir that shows up is for
> what looks like some /proc filesystem thing.
>

[snip]
[pid 24603] openat(AT_FDCWD, "/proc/146/task/146/ns", O_RDONLY|O_DIRECTORY) = 8
[pid 24603] getdents(1048577, 0x561c7bb02b90, 131072) = -1 EBADF (Bad
file descriptor)
[pid 24603] getdents(8, 0x561c7bb02b90, 0) = -1 EINVAL (Invalid argument)
[pid 24603] getdents(8, 0x561c7bb02b90 /* 12 entries */, 131072) = 328
[pid 24603] getdents(8, 0x561c7bb02b90 /* 0 entries */, 131072) = 0
[pid 24603] close(8)                    = 0
[/snip]

Calls with EBADF and EINVAL show up on my debian version and also on
the version I compiled from their repo
(https://github.com/ColinIanKing/stress-ng.git).

This runs over this collection:
               ret = stress_getdents_rand(args, "/proc", true, 8,
bad_fd, &duration, &count);
                if (ret == -ENOSYS)
                        break;
                ret = stress_getdents_rand(args, "/dev", true, 1,
bad_fd, &duration, &count);
                if (ret == -ENOSYS)
                        break;
                ret = stress_getdents_rand(args, "/tmp", true, 4,
bad_fd, &duration, &count);
                if (ret == -ENOSYS)
                        break;
                ret = stress_getdents_rand(args, "/sys", true, 8,
bad_fd, &duration, &count);
                if (ret == -ENOSYS)
                        break;
                ret = stress_getdents_rand(args, "/run", true, 2,
bad_fd, &duration, &count);
                if (ret == -ENOSYS)
                        break;

hence weird stuff mutex and rwsem stuff as well.

All in all I don't think this is a legitimate benchmark per se, but it
may be it is doing something similar to what a real workload would do
elsewhere with lockref. On that front alone it warrants figuring out
(and I am going to sort it out, see my other e-mail).

-- 
Mateusz Guzik <mjguzik gmail.com>