[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210223211639.670db85c@gandalf.local.home>
Date: Tue, 23 Feb 2021 21:16:39 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Michael Jeanson <mjeanson@...icios.com>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Alexei Starovoitov <ast@...nel.org>,
Yonghong Song <yhs@...com>,
"Paul E . McKenney" <paulmck@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Joel Fernandes <joel@...lfernandes.org>, bpf@...r.kernel.org
Subject: Re: [RFC PATCH 0/6] [RFC] Faultable tracepoints (v2)
On Thu, 18 Feb 2021 17:21:19 -0500
Michael Jeanson <mjeanson@...icios.com> wrote:
> This series only implements the tracepoint infrastructure required to
> allow tracers to handle page faults. Modifying each tracer to handle
> those page faults would be a next step after we all agree on this piece
> of instrumentation infrastructure.
I started taking a quick look at this, and came up with the question: how
do you allow preemption when dealing with per-cpu buffers or storage to
record the data?
That is, perf, bpf and ftrace are all using some kind of per-cpu data, and
this is the reason for the need to disable preemption. What's the solution
that LTTng is using for this? I know it has a per cpu buffers too, but does
it have some kind of "per task" buffer that is being used to extract the
data that can fault?
-- Steve
Powered by blists - more mailing lists