lkml.org 
[lkml]   [2019]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/3] x86/ftrace: Use text_poke()
    On Fri, 4 Oct 2019 10:10:47 +0200
    Daniel Bristot de Oliveira <bristot@redhat.com> 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:8.340 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site