[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4e0675e-caad-4a1f-85b4-6b651d8565cd@paulmck-laptop>
Date: Tue, 9 Jul 2024 09:57:39 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andrii Nakryiko <andrii.nakryiko@...il.com>,
Masami Hiramatsu <mhiramat@...nel.org>, mingo@...nel.org,
andrii@...nel.org, linux-kernel@...r.kernel.org,
rostedt@...dmis.org, oleg@...hat.com, jolsa@...nel.org,
clm@...a.com, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH 00/10] perf/uprobe: Optimize uprobes
On Tue, Jul 09, 2024 at 05:30:38PM +0100, Matthew Wilcox wrote:
> On Tue, Jul 09, 2024 at 05:10:45PM +0100, Matthew Wilcox wrote:
> > > So I fundamentally do not believe in per-VMA locking. Specifically for
> > > this case that would be trading one hot line for another. I tried
> > > telling people that, but it doesn't seem to stick :/
> >
> > SRCU also had its own performance problems, so we've got problems one
> > way or the other. The per-VMA lock probably doesn't work quite the way
> > you think it does, but it absoutely can be a hot cacheline.
> >
> > I did propose a store-free variant at LSFMM 2022 and again at 2023,
> > but was voted down. https://lwn.net/Articles/932298/
>
> Actually, the 2022 version has a bit more of the flavour of the
> argument: https://lwn.net/Articles/893906/
Thank you for the citations!
>From what I can see, part of the problem is that applications commonly
running on Linux have worked around many of these limitations one way or
another, which makes it harder to find a real-world use case for which
the store-free lookup gives substantial benefits. Perhaps this uprobes
case will be helpful in that regard. (Hey, I can dream, can't I?)
Thanx, Paul
Powered by blists - more mailing lists