All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Andrey Konovalov <andreyknvl@gmail.com>
Cc: andrey.konovalov@linux.dev,
	Alexander Potapenko <glider@google.com>,
	 Dmitry Vyukov <dvyukov@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	kasan-dev@googlegroups.com,
	 Evgenii Stepanov <eugenis@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	Andrey Konovalov <andreyknvl@google.com>
Subject: Re: [PATCH 11/15] stackdepot: use read/write lock
Date: Tue, 2 Jan 2024 13:59:06 +0100	[thread overview]
Message-ID: <CANpmjNNfyKV0Ky=GRiw9_6va3nJMtYejWZJL0tn5cjwXTY8e1Q@mail.gmail.com> (raw)
In-Reply-To: <CA+fCnZdAUo1CKDK4kiUyR+Fxc_F++CFezanPDVujx3u7fBmw=A@mail.gmail.com>

On Wed, 13 Sept 2023 at 19:09, Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> On Tue, Sep 5, 2023 at 6:19 PM Marco Elver <elver@google.com> wrote:
> >
> > > Good suggestion. I propose that we keep the rwlock for now, and I'll
> > > check whether the performance is better with percpu-rwsem once I get
> > > to implementing and testing the performance changes. I'll also check
> > > whether percpu-rwsem makes sense for stack ring in tag-based KASAN
> > > modes.
> >
> > I think it's quite obvious that the percpu-rwsem is better. A simple
> > experiment is to measure the ratio of stackdepot hits vs misses. If
> > the ratio is obviously skewed towards hits, then I'd just go with the
> > percpu-rwsem.
> >
> > The performance benefit may not be measurable if you use a small system.
>
> I started looking into using percpu-rwsem, but it appears that it
> doesn't have the irqsave/irqrestore API flavor. I suspect that it
> shouldn't be hard to add it, but I'd rather not pursue this as a part
> of this series.
>
> So I still propose to keep the rwlock for now, and switch to
> percpu-rwsem later together with the other perf changes.

I may have gotten lost in the post-vacation email avalanche and missed
it: did you already send the percpu-rwsem optimization? I am a little
worried about the contention the plain rwlock introduces on big
machines.

Thanks,
-- Marco

  reply	other threads:[~2024-01-02 12:59 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 17:11 [PATCH 00/15] stackdepot: allow evicting stack traces andrey.konovalov
2023-08-29 17:11 ` [PATCH 01/15] stackdepot: check disabled flag when fetching andrey.konovalov
2023-08-30  7:40   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 02/15] stackdepot: simplify __stack_depot_save andrey.konovalov
2023-08-30  7:41   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 03/15] stackdepot: drop valid bit from handles andrey.konovalov
2023-08-30  7:43   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 04/15] stackdepot: add depot_fetch_stack helper andrey.konovalov
2023-08-30  7:47   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 05/15] stackdepot: use fixed-sized slots for stack records andrey.konovalov
2023-08-30  8:21   ` Alexander Potapenko
2023-09-13 17:07     ` Andrey Konovalov
2023-09-15 10:36       ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 06/15] stackdepot: fix and clean-up atomic annotations andrey.konovalov
2023-08-30  8:34   ` Marco Elver
2023-09-04 18:45     ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 07/15] stackdepot: rework helpers for depot_alloc_stack andrey.konovalov
2023-08-29 17:11 ` [PATCH 08/15] stackdepot: rename next_pool_required to new_pool_required andrey.konovalov
2023-08-30  8:29   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 09/15] stackdepot: store next pool pointer in new_pool andrey.konovalov
2023-08-29 17:11 ` [PATCH 10/15] stackdepot: store free stack records in a freelist andrey.konovalov
2023-08-29 17:11 ` [PATCH 11/15] stackdepot: use read/write lock andrey.konovalov
2023-08-30  9:13   ` Marco Elver
2023-09-04 18:46     ` Andrey Konovalov
2023-09-05 16:19       ` Marco Elver
2023-09-13 17:08         ` Andrey Konovalov
2024-01-02 12:59           ` Marco Elver [this message]
2024-01-09  3:27             ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 12/15] stackdepot: add refcount for records andrey.konovalov
2023-08-30  9:32   ` Marco Elver
2023-09-04 18:46     ` Andrey Konovalov
2023-09-04 18:55       ` Marco Elver
2023-09-13 17:07         ` Andrey Konovalov
2023-09-01 13:06   ` Kuan-Ying Lee (李冠穎)
2023-09-04 18:46     ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 13/15] stackdepot: add backwards links to hash table buckets andrey.konovalov
2023-08-30  9:24   ` Marco Elver
2023-09-13 17:07     ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 14/15] stackdepot: allow users to evict stack traces andrey.konovalov
2023-08-30  9:20   ` Marco Elver
2023-09-04 18:47     ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 15/15] kasan: use stack_depot_evict for tag-based modes andrey.konovalov
2023-08-30  9:38   ` Marco Elver
2023-09-04 18:48     ` Andrey Konovalov
2023-09-04 18:58       ` Marco Elver
2023-09-13 17:08         ` Andrey Konovalov
2023-08-30  7:46 ` [PATCH 00/15] stackdepot: allow evicting stack traces Vlastimil Babka
2023-09-04 18:45   ` Andrey Konovalov
2023-09-05  2:48     ` Kuan-Ying Lee (李冠穎)
2023-09-13 17:10       ` Andrey Konovalov

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='CANpmjNNfyKV0Ky=GRiw9_6va3nJMtYejWZJL0tn5cjwXTY8e1Q@mail.gmail.com' \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrey.konovalov@linux.dev \
    --cc=andreyknvl@gmail.com \
    --cc=andreyknvl@google.com \
    --cc=dvyukov@google.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.