lkml.org 
[lkml]   [2013]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 3/3] tracing: Teach FETCH_MTD_{symbol,deref} to handle per-cpu data
(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. If the symbol is
percpu, it should be automatically translated to something like
FETCH_percpu, instead of such additional expression.

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

> We could turn {dprm,sc}->offset into the "struct probe_offset" which
> holds offset + is_percpu, but this hack looks simple enough and I hope
> that LONG_MAX/2 is enough for the numeric offset.

Also, please do not be afraid to add fetch operation, such kind of
is_percpu flag is not dynamically changed. Then we can use another
fetch function.

Thank you,



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




\
 
 \ /
  Last update: 2013-11-26 11:01    [W:0.208 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site