This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Forw: Re: [17/19] ftrace: dynamic enabling/disabling of function calls
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: systemtap at sources dot redhat dot com
- Date: Sun, 10 Feb 2008 23:03:49 -0500
- Subject: Forw: Re: [17/19] ftrace: dynamic enabling/disabling of function calls
- References: <20080210072109.GR4100@elte.hu>
The following blurb from LKML suggests a possible way to implement
batched kprobe (un)registration too.
> Ingo Molnar <mingo@elte.hu> writes:
> From: Steven Rostedt <srostedt@redhat.com>
>
> This patch adds a feature to dynamically replace the ftrace code
> with the jmps to allow a kernel with ftrace configured to run
> as fast as it can without it configured.
>
> The way this works, is on bootup, a ftrace function is registered
> to record the instruction pointer of all places that call the
> function.
>
> Later, a kthread is awoken once a second that performs a stop_machine,
> and replaces all the code that was called with a jmp over the call
> to ftrace. It only replaces what was found the previous time.
>
> e.g.
>
> call ftrace /* 5 bytes */
>
> is replaced with
>
> jmp 3f /* jmp is 2 bytes and we jump 3 forward */
> 3:
>
> When we want to enable ftrace for function tracing, the IP recording
> is removed, and stop_machine is called again to replace all the locations
> of that were recorded back to the call of ftrace. When it is disabled,
> we replace the code back to the jmp.
>
> Allocation is done by the kthread. If the ftrace recording function is
> called, and we don't have any record slots available, then we simply
> skip that call. Once a second a new page (if needed) is allocated for
> recording new ftrace function calls. A large batch is allocated at
> boot up to get most of the calls there.
>
> Because we do this via stop_machine, we don't have to worry about another
> CPU executing a ftrace call as we modify it. But we do need to worry
> about NMI's so all functions that might be called via nmi must be
> annotated with notrace_nmi. When this code is configured in, the NMI code
> will not call notrace.
> [...]
- FChE