[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52946B42.40603@hitachi.com>
Date: Tue, 26 Nov 2013 18:34:58 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Namhyung Kim <namhyung.kim@....com>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...hat.com>, Jiri Olsa <jolsa@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [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@...achi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists