Re: [PATCH 3/3] arm64: ftrace: add cond_resched() to func ftrace_make_(call|nop)
From: Will Deacon
Date: Mon Dec 03 2018 - 14:22:11 EST
Hi Anders,
On Fri, Nov 30, 2018 at 04:09:56PM +0100, Anders Roxell wrote:
> Both of those functions end up calling ftrace_modify_code(), which is
> expensive because it changes the page tables and flush caches.
> Microseconds add up because this is called in a loop for each dyn_ftrace
> record, and this triggers the softlockup watchdog unless we let it sleep
> occasionally.
> Rework so that we call cond_resched() before going into the
> ftrace_modify_code() function.
>
> Co-developed-by: Arnd Bergmann <arnd@xxxxxxxx>
> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> Signed-off-by: Anders Roxell <anders.roxell@xxxxxxxxxx>
> ---
> arch/arm64/kernel/ftrace.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
It sounds like you're running into issues with the existing code, but I'd
like to understand a bit more about exactly what you're seeing. Which part
of the ftrace patching is proving to be expensive?
The page table manipulation only happens once per module when using PLTs,
and the cache maintenance is just a single line per patch site without an
IPI.
Is it the loop in ftrace_replace_code() that is causing the hassle?
Will