linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>


  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