On Fri, 4 Oct 2019 10:10:47 +0200 Daniel Bristot de Oliveira <[email protected]> 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 > >
