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

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

(2013/11/28 2:41), Oleg Nesterov wrote:
> On 11/27, Masami Hiramatsu wrote:
>>
>> (2013/11/27 2:43), Oleg Nesterov wrote:
>>>
>>> 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.
>>
>> Yeah, usually per_cpu variable is used in current cpu context.
>>
>>>> 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...
>>
>> No, it is enough to provide "percpu(FETCHARG)" which just returns
>> current cpu's percpu variable address.
> 
> I don't really agree. I am not saying this is terribly useful, but:
> 
>> (Note that kprobes handler
>> runs in interrupt)
> 
> but this doesn't matter at all, I think. The code can execute, say,
> __percpu_counter_sum-like code.
>
> And even if we dump the .data..percpu memory (@percpu_symbol) the
> user might want to know the "global" state of this per-cpu object.

I see, but it is the problem solved in the next step.
IMHO, giving people to access just to this cpu's variable is enough
useful. Expanding it to other cpu is another one.

> And note that sometimes DEFINE_PER_CPU doesn't really connect to
> smp_processor_id(). Just for example, bp_cpuinfo[]. It is never
> used as this-cpu-data. This means that @bp_cpuinfo+whatever is
> always pointless.

Yeah, there should be some exceptions.

> But anyway I agree, this is not that important, lets ignore.

 :)

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com