[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250519151238.GB17177@willie-the-truck>
Date: Mon, 19 May 2025 16:12:39 +0100
From: Will Deacon <will@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Nam Cao <namcao@...utronix.de>, Gabriele Monaco <gmonaco@...hat.com>,
linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
john.ogness@...utronix.de,
Catalin Marinas <catalin.marinas@....com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v6 17/22] arm64: mm: Add page fault trace points
On Fri, May 16, 2025 at 10:42:48AM -0400, Steven Rostedt wrote:
>
>
> On May 16, 2025 10:04:50 AM EDT, Will Deacon <will@...nel.org> wrote:
> >
> >> + if (user_mode(regs))
> >> + trace_page_fault_user(addr, regs, esr);
> >> + else
> >> + trace_page_fault_kernel(addr, regs, esr);
> >
> >Why is this after kprobe_page_fault()?
> >
> >It's also a shame that the RV monitor can't hook into perf, as we
> >already have a sw event for page faults that you could use instead of
> >adding something new.
> >
>
> Perf events work for perf only. My question is why isn't this a tracepoint
> that perf could hook into?
Well, the perf event came first in this case, so we're stuck with it :/
I was hoping we could settle for a generic helper that could emit both
the trace event and the perf event (so that the ordering of the two is
portable across architectures) but, judging by Nam's reply, the trace
event is needed before kprobes gets a look in.
Will
Powered by blists - more mailing lists