Re: [RFC PATCH 1/2] tracing/stat: introduce new hashlist mode

[Li Zefan <lizf@cn.fujitsu.com>]

Frederic Weisbecker wrote:
> Until now, the stat tracing was only able to gather the pointers
> to entries from a tracer, sort them and eventually pass these
> pointers to the tracer output handler.
> 
> It has two drawbacks:
> 
> - if the tracer concurrently releases a pointer, this one may be
>   dereference later in the output callback. There are ways to keep
>   track of these pointers but it ends up with extra code from the
>   tracers.
> 
> - the tracer has to handle its entries itself, through its own
>   hashlist, list or whatever.
> 

indeed

> This patch introduces a new mode for the stat tracers. Those can now
> ask the tracing stat Api to handle their entries, which includes the
> memory allocation, the access, the synchronization, the lookup, etc...
> 
> This is done through an internal hashlist that is built according
> to the number and size of entries provided by the tracer.
> 

But hashlist may not be suitable for all stat tracers?

> A tracer can choose between this new mode and the old one by using
> the HASH_NODES flag in struct tracer_stat.
> 

What's the advantages of the old mode towards this new mode?
I think it's better to move all existing stat tracers to
this new mode, and remove the old mode totally, if we want
this new mode.

> Instead of providing a pair of iterator callbacks, they just need
> to fill up the hlist_size and node_size fields.
> 
> Then using a unique id for each stat entries (usually a simple address
> to a traced thing), they can access to an entry using the two new pairs:
> 
> - get_stat_entry() which retrieve the entry and locks it against
>   concurrent updates
> - put_stat_entry() which unlocks the entry
> 
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> ---
>  kernel/trace/trace_stat.c |  329 ++++++++++++++++++++++++++++++++++++++++++++-
>  kernel/trace/trace_stat.h |   27 ++++-
>  2 files changed, 353 insertions(+), 3 deletions(-)