Re: [RFC PATCH 09/10] tracing: Use the hashlist for graph function

From: Frederic Weisbecker
Date: Sat Jan 30 2010 - 16:19:52 EST


On Mon, Jan 25, 2010 at 04:50:48PM +0800, Lai Jiangshan wrote:
> Frederic Weisbecker wrote:
> > When we set a filter to start tracing from a given function in
> > the function graph tracer, the filter is stored in a linear array.
> >
> > It doesn't scale very well, we even limited the number of such
> > functions to 32.
> >
> > Now that we have a hashlist of functions, lets put a field inside
> > each function node so that we can check if a function is one of
> > these filters using the hashlist, not a linear array.
>
> The linear array @ftrace_graph_funcs is still used in this patch.
> we still limit the number of such functions to 32?
>
> [...]



Heh, that's right. I should probably make it a list. The array
is only used when we touch set_graph_function file.



> > #define FTRACE_GRAPH_MAX_FUNCS 32
> > extern int ftrace_graph_count;
> > extern unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS];
> > -
> > -static inline int ftrace_graph_addr(unsigned long addr)
> > -{
> > - int i;
> > -
> > - if (!ftrace_graph_count)
> > - return 1;
>
> Here return 1.
>
> [...]
> > +static inline int ftrace_graph_addr(unsigned long addr)
> > +{
> > + struct func_node *rec;
> > + struct func_hlist *hlist;
> > +
> > + if (!ftrace_graph_count)
> > + return 0;
> > +
>
> But in this patch, return 0 here, the behave will be changed.


Yeah, I've inverted the check from the tracing callback.

It seems to me that:

if (ftrace_graph_addr(addr))

more logically means that we trace this addr. Making it
a boolean would make the things more clear perhaps?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/