Date:	Fri, 20 Dec 2013 11:46:15 +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:

> (2013/12/20 17:20), Ingo Molnar wrote:
> > 
> > * Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> wrote:
> > 
> >>>  But a closer look indicates that the insertion of kprobes is 
> >>> taking about three (!!) orders of magnitude longer than before, as 
> >>> judged by the rate of increase of 'wc -l 
> >>> /sys/kernel/debug/kprobes/list'.
> >>
> >> Right, because kprobes are not designed for thousands of probes.
> > 
> > Then this needs to be fixed, because right now this bug is making it 
> > near impossible to properly test kprobes robustness.
> > 
> > For example a hash table (hashed by probe address) could be used in 
> > addition to the list, to speed up basic operations.
> 
> kprobe itself is already using hlist (6bits hash table).
> Maybe we'd better expand the table bits. However, the iteration
> of the list on debugfs is just doing seq_printf()s. I'm not exactly
> sure what Frank complaints about...

Well, Frank reported that the test he performed takes hours to finish, 
and he mentioned a specific script line he used to produce that:

  # stap -te "probe kprobe.function("*") {}"

I suspect an equivalent perf probe sequence would be something like:

  # for FUNC in $(grep -iw t /proc/kallsyms | cut -d' ' -f3); do date; perf probe -a $FUNC; done

(totally untested.)

Can you reproduce that slowdown, using his method?

I can reproduce one weirdness, with just 13 probes added, 'perf probe 
-l' [which should really be 'perf probe list'!] executes very slowly:

 # perf stat --null --repeat 3 perf probe -l

 Performance counter stats for 'perf probe -l' (3 runs):

       0.763640098 seconds time elapsed                                          ( +-  1.61% )

0.7 seconds is ridiculously long.

Also, here's another bugreport as well: while playing around with 
'perf probe' I found that its usability is still very poor. For 
example I mis-remembered the syntax and typed the obvious way to :

 # perf probe add __schedule
 Failed to find path of kernel module.
 Failed to open debuginfo file.
   Error: Failed to add events. (-2)

why the heck does a simple and obvious 'perf probe add' not work, why 
is the strange syntax of 'perf probe -a' forced? Every other perf 
subcommand uses clean command spaces - see for example 'perf bench'.

Also, the error message is totally misleading and uninformative to the 
level of being passive-aggressive. An error message should directly 
relate to the mistake performed and should give a good way out of the 
situation. Who the heck cares that there was no debuginfo file to 
open? Who cares that the 'path of kernel module' was not found? It has 
no relation to the bug.

An informative error message would be:

 # perf probe add __schedule
 Error: Could not find symbol 'add'.

and that's it. No 'failed to add events' message - obviously the event 
is not enabled if we cannot find the symbol name.

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