From: Mateusz Guzik <mjguzik@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: kernel test robot <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
Linux Memory Management List <linux-mm@kvack.org>,
Christian Brauner <brauner@kernel.org>,
linux-kernel@vger.kernel.org, ying.huang@intel.com,
feng.tang@intel.com, fengwei.yin@intel.com
Subject: Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression
Date: Thu, 27 Jun 2024 19:20:03 +0200 [thread overview]
Message-ID: <CAGudoHGuf8JZJjMcs+aYPN7jH+q6Og2CNvSg1-qjJ8kH6SJbJg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wjkn=yL6vy5s7ZFgBfDybD3Gjg9C72zXchy-JF0Tp+a+A@mail.gmail.com>
On Thu, Jun 27, 2024 at 6:57 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Thu, 27 Jun 2024 at 09:32, Linus Torvalds
> <torvalds@linux-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>
next prev parent reply other threads:[~2024-06-27 17:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-27 2:41 kernel test robot
2024-06-27 6:25 ` Mateusz Guzik
2024-06-27 7:00 ` Mateusz Guzik
2024-06-27 16:32 ` Linus Torvalds
2024-06-27 16:55 ` Mateusz Guzik
2024-06-27 16:57 ` Linus Torvalds
2024-06-27 17:20 ` Mateusz Guzik [this message]
2024-06-27 17:23 ` Linus Torvalds
2024-07-02 7:19 ` Mateusz Guzik
2024-07-02 12:10 ` Mateusz Guzik
2024-07-02 16:47 ` Linus Torvalds
2024-07-02 17:02 ` Mateusz Guzik
2024-07-02 17:28 ` Linus Torvalds
2024-07-02 17:46 ` Mateusz Guzik
2024-07-02 17:58 ` Mateusz Guzik
2024-07-02 18:41 ` Linus Torvalds
2024-07-02 20:33 ` Mateusz Guzik
2024-07-02 20:42 ` Linus Torvalds
2024-07-02 21:15 ` Mateusz Guzik
2024-07-02 22:14 ` Linus Torvalds
2024-07-03 13:53 ` Mateusz Guzik
2024-07-03 14:08 ` Christian Brauner
2024-07-03 14:11 ` Mateusz Guzik
2024-07-03 16:47 ` Linus Torvalds
2024-07-03 8:34 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGudoHGuf8JZJjMcs+aYPN7jH+q6Og2CNvSg1-qjJ8kH6SJbJg@mail.gmail.com \
--to=mjguzik@gmail.com \
--cc=brauner@kernel.org \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox