[RFC PATCH 0/2] tracing: Teach FETCH_MTD_symbol to handle per-cpu data

[Oleg Nesterov <oleg@redhat.com>]

On 11/26, Masami Hiramatsu wrote:
>
> (2013/11/26 2:22), Oleg Nesterov wrote:
> > @symbol can't be used to dump the per-cpu variables. The same is
> > true for +offset(something) if "something" results in __percpu
> > pointer.
> >
> > With this patch parse_probe_offset() treats "~" before the numeric
> > offset as "per cpu" mark and stores it in the lowest bit,
> > calc_probe_offset() simply adds per_cpu_offset(smp_processor_id())
> > if this bit is set.
>
> IMHO, if the symbol is a per-cpu symbol, it is meaningless to
> access the symbol itself. For the symbol(static) percpu, maybe
> we can use is_kernel_percpu_address() to check.

No, we can't use is_kernel_percpu_address(), this is another thing.
is_kernel_percpu_address(&my_pcpu_var) == F. It is true for
&per_cpu(my_pcpu_var), this is not what we need.

> If the symbol is
> percpu, it should be automatically translated to something like
> FETCH_percpu, instead of such additional expression.

OK. Probably yes, it should be automatically translated, please
see the patches.

This doesn't allow to read the data from other CPUs, but at least
the changes are simple and this_cpu_ is better than the reading
from the obviously wrong address.

> For the dynamic allocated per-cpu things, it is also good to give
> a straight operation, like +10(percpu(%rdi)).

Probably yes, but this needs more changes and I am still not sure
this is really useful. And if we do this, we probably also need
to allow to read from other CPUs...

> Also, please do not be afraid to add fetch operation,

Well, this is what I am trying to avoid ;)

Oleg.