[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240704095637.0dbf9483@rorschach.local.home>
Date: Thu, 4 Jul 2024 09:56:37 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>, Andrii Nakryiko
<andrii@...nel.org>, linux-trace-kernel@...r.kernel.org,
mhiramat@...nel.org, oleg@...hat.com, mingo@...hat.com,
bpf@...r.kernel.org, jolsa@...nel.org, paulmck@...nel.org, clm@...a.com,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 00/12] uprobes: add batched register/unregister APIs
and per-CPU RW semaphore
On Thu, 4 Jul 2024 11:15:59 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
> > Now, RCU Tasks Trace were specifically designed for least overhead
> > hotpath (reader side) performance, at the expense of slowing down much
> > rarer writers. My microbenchmarking does show at least 5% difference.
> > Both flavors can handle sleepable uprobes waiting for page faults.
> > Tasks Trace flavor is already used for tracing in the BPF realm,
> > including for sleepable uprobes and works well. It's not going away.
>
> I need to look into this new RCU flavour and why it exists -- for
> example, why can't SRCU be improved to gain the same benefits. This is
> what we've always done, improve SRCU.
I don't know about this use case, but for the trampoline use case SRCU
doesn't work as it requires calling a srcu_read_lock() which isn't
possible when you need to take that lock from all function calls just
before it jumps to the ftrace trampoline. That is, it needs to be taken
before "call fentry".
I'm just stating this to provide the reason why we needed that flavor
of RCU.
-- Steve
Powered by blists - more mailing lists