[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140209143709.GA31608@gmail.com>
Date: Sun, 9 Feb 2014 15:37:09 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc: "Frank Ch. Eigler" <fche@...hat.com>, linux-arch@...r.kernel.org,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Sandeepa Prabhu <sandeepa.prabhu@...aro.org>, x86@...nel.org,
lkml <linux-kernel@...r.kernel.org>,
"Steven Rostedt (Red Hat)" <rostedt@...dmis.org>,
systemtap@...rceware.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(),
cleanup and fixes crash bugs
* Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> wrote:
> I guess the second reason is why the stap takes so long time to set
> probes. stap tries to register kprobes without disabled flag, that
> means we enables thousands of probes (overheads).
>
> So the similar thing happens when we enables events as below;
>
> # for i in /sys/kernel/debug/tracing/events/kprobes/* ; do date; echo 1 > $i; done
> Wed Jan 29 10:44:50 UTC 2014
> ...
>
> I tried it and canceled after 4 min passed. It enabled about 17k
> events and slowed down my system very much(I almost got hang check
> timer).
Ok, I guess that's the slowdown bug that Frank reported.
> I think we should have some performance statistics (hit count?) and
> if it goes over a threshold, we should stop enabling other events.
That really feels like a hack. How about fixing the root cause? Does
the enabling of all probes have to be so slow?
Thanks,
Ingo
--
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