[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140209212724.GA6892@redhat.com>
Date: Sun, 9 Feb 2014 16:27:24 -0500
From: "Frank Ch. Eigler" <fche@...hat.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@...achi.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
Hi -
> > 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.
It could be, but it feels a bit different. In my testing from
December, it's as though it wasn't the activated probes *hitting* that
were associated with the slowdown, but them merely being activated.
It was as though something with the kprobes/ftrace probe-registration
code performed a lot more work than it did longer ago. (One way to
test this could be to be more careful in the selection of kprobes
being enabled. For examle, emplace thousands, but only unused loaded
modules.) I'm sorry I didn't get time to investigate further.
- FChE
--
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