Hi,
On Tue, 4 Jun 2024, Song Liu wrote:
> On Tue, May 21, 2024 at 1:04 AM Petr Mladek <pmladek@xxxxxxxx> wrote:
> [...]
> > >
> > > Yes, but the information you get is limited compared to what is available
> > > now. You would obtain the information that a patched function was called
> > > but ftrace could also give you the context and more.
> >
> > Another motivation to use ftrace for testing is that it does not
> > affect the performance in production.
> >
> > We should keep klp_ftrace_handler() as fast as possible so that we
> > could livepatch also performance sensitive functions.
>
> At LPC last year, we discussed about adding a counter to each
> klp_func, like:
>
> struct klp_func {
> ...
> u64 __percpu counter;
> ...
> };
>
> With some static_key (+ sysctl), this should give us a way to estimate
> the overhead of livepatch. If we have the counter, this patch is not
> needed any more. Does this (adding the counter) sound like
> something we still want to pursue?
It would be better than this patch but given what was mentioned in the
thread I wonder if it is possible to use ftrace even for this. See
/sys/kernel/tracing/trace_stat/function*. It already gathers the number of
hits.
Would it be sufficient for you? I guess it depends on what the intention
is. If there is no time limit, klp_func.counter might be better to provide
some kind of overall statistics (but I am not sure if it has any value)
and to avoid having ftrace registered on a live patched function for
infinite period of time. If the intention is to gather data for some
limited period, trace_stat sounds like much better approach to me.
Regards
Miroslav
