[lkml]   [2019]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/3] x86/ftrace: Use text_poke()
On Fri, 4 Oct 2019 10:10:47 +0200
Daniel Bristot de Oliveira <> wrote:

> [ In addition ]
> Currently, ftrace_rec entries are ordered inside the group of functions, but
> "groups of function" are not ordered. So, the current int3 handler does a (*):
> for_each_group_of_functions:
> check if the ip is in the range ----> n by the number of groups.
> do a bsearch. ----> log(n) by the numbers of entry
> in the group.
> If, instead, it uses an ordered vector, the complexity would be log(n) by the
> total number of entries, which is better. So, how bad is the idea of:

BTW, I'm currently rewriting the grouping of the vectors, in order to
shrink the size of each dyn_ftrace_rec (as we discussed at Kernel
Recipes). I can make the groups all sorted in doing so, thus we can
load the sorted if that's needed, without doing anything special.

> in the enabling ftrace code path, it:
> discover the number of entries
> alloc a buffer
> discover the order of the groups
> for each group in the correct order
> queue the entry in the buffer
> apply the changes using the text_poke...
> In this way we would optimize the two hot-paths:
> int3 will be log(n)
> IPIs bounded to 3.
> I am not saying we need to do it now, as Steve said, not sure if this is a big
> problem, but... those that don't like kernel interference may complain. But if
> we leave the per-use-case vector in the text_poke_batch interface, things will
> be easier to fix.
> NOTE: the other IPIs are generated by hooking the tracepoints and switching the
> code to RO/RW...

Yeah, I did a trace of who is doing the on_each_cpu() call, and saw it
coming from the RO/RW changes, which this patch series removes.

-- Steve

> * as far as I understood ftrace_location_range().
> -- Daniel
> > -- Steve
> >

 \ /
  Last update: 2019-10-04 15:40    [W:0.228 / U:6.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site