From: Li Zefan <lizf@cn.fujitsu.com> To: Ingo Molnar <mingo@elte.hu> Cc: Pekka Enberg <penberg@cs.helsinki.fi>, Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>, Peter Zijlstra <peterz@infradead.org>, Frederic Weisbecker <fweisbec@gmail.com>, LKML <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org> Subject: Re: [PATCH 0/5] perf kmem: Add more functions and show more statistics Date: Tue, 24 Nov 2009 17:38:37 +0800 [thread overview] Message-ID: <4B0BA99D.5020602@cn.fujitsu.com> (raw) In-Reply-To: <20091124090425.GF21991@elte.hu> Ingo Molnar wrote: > a few more UI suggestions for 'perf kmem': > Thanks for the suggestions! > I think it should look similar to how 'perf' and 'perf sched' prints > sub-commands with increasing specificity, which means that we display a > list of subcommands and options when typed: > Yes, I'd like to make the usage and output format similar to perf-sched. > $ perf sched > > usage: perf sched [<options>] {record|latency|map|replay|trace} > > -i, --input <file> input file name > -v, --verbose be more verbose (show symbol address, etc) > -D, --dump-raw-trace dump raw trace in ASCII > > > For 'perf kmem' we could print something like: > > $ perf kmem > > usage: perf kmem [<options>] {record|report|trace} > > -i, --input <file> input file name > -v, --verbose be more verbose (show symbol address, etc) > -D, --dump-raw-trace dump raw trace in ASCII > > The advantage is that right now, when a new user sees the subcommand in > 'perf' output: > > $ perf > ... > kmem Tool to trace/measure kernel memory(slab) properties > ... > > And types 'perf kmem', the following is displayed currently: > > $ perf kmem > > SUMMARY > ======= > Total bytes requested: 0 > Total bytes allocated: 0 > Total bytes wasted on internal fragmentation: 0 > Internal fragmentation: 0.000000% > Cross CPU allocations: 0/0 > > That's not very useful to someone who tries to figure out how to use > this command. A summary page would be more useful - and that would > advertise all the commands in a really short summary form (shorter than > -h/--help). > perf-timechart acts similarly - it won't show help page by "perf timechart" # ./perf timechart 0xbc480 [0x18]: skipping unknown header type: 2 0xbc488 [(nil)]: skipping unknown header type: 238 0xbc490 [(nil)]: skipping unknown header type: 20034 Written 1.0 seconds of trace to output.svg. But sure, I can change this for perf-kmem. So, do we want to do the same for perf-timechart too? > The other thing is that if someone types 'perf kmem record', the command > seems 'hung': > > $ perf kmem record > <hang> > > Now if i Ctrl-C it i see that a recording session was going on: > > $ perf kmem record > ^C[ perf record: Woken up 10 times to write data ] > [ perf record: Captured and wrote 1.327 MB perf.data (~57984 samples) ] > > but this was not apparent from the tool output and the user was left > wondering about what is going on. > > I think at minimum we should print a: > > [ Recording all kmem events in the system, Ctrl-C to stop. ] > > line. (on a related note, 'perf sched record' needs such a fix too.) > Yes, I followed perf-sched and perf-timechart. ;) I'll fix it for these tools. > Another solution would be for 'perf kmem record' to work analogous to > 'perf record': it could display a short help page by default, something > like: > > $ perf kmem record > > usage: perf kmem record [<options>] [<command>] > > example: perf kmem record -a sleep 10 # capture all events for 10 seconds > perf kmem record /bin/ls # capture events of this command > perf kmem record -p 1234 # capture events of PID 1234 > > What do you think? > But I'm not sure I like this, actually I prefer to just print a line to explain what's going on. > Also, a handful of mini-bugreports wrt. usability: > > 1) > > running 'perf kmem' without having a perf.data gives: > > earth4:~/tip/tools/perf> ./perf kmem > Failed to open file: perf.data (try 'perf record' first) > > SUMMARY > ======= > Total bytes requested: 0 > Total bytes allocated: 0 > Total bytes wasted on internal fragmentation: 0 > Internal fragmentation: 0.000000% > Cross CPU allocations: 0/0 > Again, this issue exists in perf-sched too.. So we need to fix not only perf-kmem. > 2) > > running 'perf kmem record' on a box without kmem events gives: > > earth4:~/tip/tools/perf> ./perf kmem record > invalid or unsupported event: 'kmem:kmalloc' > Run 'perf list' for a list of valid events > > i think we want to print something kmem specific - and tell the user how > to enable kmem events or so - 'perf list' is not a solution to him. > ditto > 3) > > it doesnt seem to be working on one of my boxes, which has perf and kmem > events as well: > > aldebaran:~/linux/linux/tools/perf> perf kmem record > ^C[ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.050 MB perf.data (~2172 samples) ] > Seems no kmem event is recorded. No sure what happened here. Might be that the parameters that perf-kmem passes to perf-record are not properly selected? Do perf-sched and perf-timechart work on this box? > aldebaran:~/linux/linux/tools/perf> perf kmem > > SUMMARY > ======= > Total bytes requested: 0 > Total bytes allocated: 0 > Total bytes wasted on internal fragmentation: 0 > Internal fragmentation: 0.000000% > Cross CPU allocations: 0/0 > aldebaran:~/linux/linux/tools/perf> >
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizf@cn.fujitsu.com> To: Ingo Molnar <mingo@elte.hu> Cc: Pekka Enberg <penberg@cs.helsinki.fi>, Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>, Peter Zijlstra <peterz@infradead.org>, Frederic Weisbecker <fweisbec@gmail.com>, LKML <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org> Subject: Re: [PATCH 0/5] perf kmem: Add more functions and show more statistics Date: Tue, 24 Nov 2009 17:38:37 +0800 [thread overview] Message-ID: <4B0BA99D.5020602@cn.fujitsu.com> (raw) In-Reply-To: <20091124090425.GF21991@elte.hu> Ingo Molnar wrote: > a few more UI suggestions for 'perf kmem': > Thanks for the suggestions! > I think it should look similar to how 'perf' and 'perf sched' prints > sub-commands with increasing specificity, which means that we display a > list of subcommands and options when typed: > Yes, I'd like to make the usage and output format similar to perf-sched. > $ perf sched > > usage: perf sched [<options>] {record|latency|map|replay|trace} > > -i, --input <file> input file name > -v, --verbose be more verbose (show symbol address, etc) > -D, --dump-raw-trace dump raw trace in ASCII > > > For 'perf kmem' we could print something like: > > $ perf kmem > > usage: perf kmem [<options>] {record|report|trace} > > -i, --input <file> input file name > -v, --verbose be more verbose (show symbol address, etc) > -D, --dump-raw-trace dump raw trace in ASCII > > The advantage is that right now, when a new user sees the subcommand in > 'perf' output: > > $ perf > ... > kmem Tool to trace/measure kernel memory(slab) properties > ... > > And types 'perf kmem', the following is displayed currently: > > $ perf kmem > > SUMMARY > ======= > Total bytes requested: 0 > Total bytes allocated: 0 > Total bytes wasted on internal fragmentation: 0 > Internal fragmentation: 0.000000% > Cross CPU allocations: 0/0 > > That's not very useful to someone who tries to figure out how to use > this command. A summary page would be more useful - and that would > advertise all the commands in a really short summary form (shorter than > -h/--help). > perf-timechart acts similarly - it won't show help page by "perf timechart" # ./perf timechart 0xbc480 [0x18]: skipping unknown header type: 2 0xbc488 [(nil)]: skipping unknown header type: 238 0xbc490 [(nil)]: skipping unknown header type: 20034 Written 1.0 seconds of trace to output.svg. But sure, I can change this for perf-kmem. So, do we want to do the same for perf-timechart too? > The other thing is that if someone types 'perf kmem record', the command > seems 'hung': > > $ perf kmem record > <hang> > > Now if i Ctrl-C it i see that a recording session was going on: > > $ perf kmem record > ^C[ perf record: Woken up 10 times to write data ] > [ perf record: Captured and wrote 1.327 MB perf.data (~57984 samples) ] > > but this was not apparent from the tool output and the user was left > wondering about what is going on. > > I think at minimum we should print a: > > [ Recording all kmem events in the system, Ctrl-C to stop. ] > > line. (on a related note, 'perf sched record' needs such a fix too.) > Yes, I followed perf-sched and perf-timechart. ;) I'll fix it for these tools. > Another solution would be for 'perf kmem record' to work analogous to > 'perf record': it could display a short help page by default, something > like: > > $ perf kmem record > > usage: perf kmem record [<options>] [<command>] > > example: perf kmem record -a sleep 10 # capture all events for 10 seconds > perf kmem record /bin/ls # capture events of this command > perf kmem record -p 1234 # capture events of PID 1234 > > What do you think? > But I'm not sure I like this, actually I prefer to just print a line to explain what's going on. > Also, a handful of mini-bugreports wrt. usability: > > 1) > > running 'perf kmem' without having a perf.data gives: > > earth4:~/tip/tools/perf> ./perf kmem > Failed to open file: perf.data (try 'perf record' first) > > SUMMARY > ======= > Total bytes requested: 0 > Total bytes allocated: 0 > Total bytes wasted on internal fragmentation: 0 > Internal fragmentation: 0.000000% > Cross CPU allocations: 0/0 > Again, this issue exists in perf-sched too.. So we need to fix not only perf-kmem. > 2) > > running 'perf kmem record' on a box without kmem events gives: > > earth4:~/tip/tools/perf> ./perf kmem record > invalid or unsupported event: 'kmem:kmalloc' > Run 'perf list' for a list of valid events > > i think we want to print something kmem specific - and tell the user how > to enable kmem events or so - 'perf list' is not a solution to him. > ditto > 3) > > it doesnt seem to be working on one of my boxes, which has perf and kmem > events as well: > > aldebaran:~/linux/linux/tools/perf> perf kmem record > ^C[ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.050 MB perf.data (~2172 samples) ] > Seems no kmem event is recorded. No sure what happened here. Might be that the parameters that perf-kmem passes to perf-record are not properly selected? Do perf-sched and perf-timechart work on this box? > aldebaran:~/linux/linux/tools/perf> perf kmem > > SUMMARY > ======= > Total bytes requested: 0 > Total bytes allocated: 0 > Total bytes wasted on internal fragmentation: 0 > Internal fragmentation: 0.000000% > Cross CPU allocations: 0/0 > aldebaran:~/linux/linux/tools/perf> > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-11-24 9:39 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-11-24 5:25 [PATCH 0/5] perf kmem: Add more functions and show more statistics Li Zefan 2009-11-24 5:25 ` Li Zefan 2009-11-24 5:25 ` [PATCH 1/5] perf kmem: Add new option to show raw ip Li Zefan 2009-11-24 5:25 ` Li Zefan 2009-11-24 16:54 ` [tip:perf/core] " tip-bot for Li Zefan 2009-11-24 16:54 ` tip-bot for Li Zefan 2009-11-24 5:26 ` [PATCH 2/5] perf kmem: Default to sort by fragmentation Li Zefan 2009-11-24 5:26 ` Li Zefan 2009-11-24 16:55 ` [tip:perf/core] " tip-bot for Li Zefan 2009-11-24 16:55 ` tip-bot for Li Zefan 2009-11-24 5:26 ` [PATCH 3/5] perf kmem: Collect cross node allocation statistics Li Zefan 2009-11-24 5:26 ` Li Zefan 2009-11-24 16:55 ` [tip:perf/core] " tip-bot for Li Zefan 2009-11-24 16:55 ` tip-bot for Li Zefan 2009-11-24 5:26 ` [PATCH 4/5] perf kmem: Measure kmalloc/kfree CPU ping-pong call-sites Li Zefan 2009-11-24 5:26 ` Li Zefan 2009-11-24 16:55 ` [tip:perf/core] " tip-bot for Li Zefan 2009-11-24 16:55 ` tip-bot for Li Zefan 2009-11-24 5:27 ` [PATCH 5/5] perf kmem: Add help file Li Zefan 2009-11-24 5:27 ` Li Zefan 2009-11-24 16:55 ` [tip:perf/core] " tip-bot for Li Zefan 2009-11-24 16:55 ` tip-bot for Li Zefan 2009-11-24 7:15 ` [PATCH 0/5] perf kmem: Add more functions and show more statistics Pekka Enberg 2009-11-24 7:15 ` Pekka Enberg 2009-11-24 7:34 ` Ingo Molnar 2009-11-24 7:34 ` Ingo Molnar 2009-11-24 7:45 ` Pekka Enberg 2009-11-24 7:45 ` Pekka Enberg 2009-11-24 7:47 ` Ingo Molnar 2009-11-24 7:47 ` Ingo Molnar 2009-11-24 8:04 ` Li Zefan 2009-11-24 8:04 ` Li Zefan 2009-11-24 8:34 ` Ingo Molnar 2009-11-24 8:34 ` Ingo Molnar 2009-11-24 14:57 ` Arjan van de Ven 2009-11-24 14:57 ` Arjan van de Ven 2009-11-24 7:18 ` Pekka Enberg 2009-11-24 7:18 ` Pekka Enberg 2009-11-24 9:04 ` Ingo Molnar 2009-11-24 9:38 ` Li Zefan [this message] 2009-11-24 9:38 ` Li Zefan 2009-11-24 10:07 ` Ingo Molnar 2009-11-24 11:04 ` Li Zefan 2009-11-24 11:04 ` Li Zefan 2009-11-24 20:35 ` Ingo Molnar 2009-11-24 20:35 ` Ingo Molnar 2009-11-24 22:34 ` Ingo Molnar 2009-11-24 22:34 ` Ingo Molnar 2009-11-24 18:49 ` Frederic Weisbecker 2009-11-24 18:49 ` Frederic Weisbecker 2009-11-24 19:38 ` [PATCH] perf: Fix bad software/trace event recursion counting Frederic Weisbecker 2009-11-24 20:36 ` [tip:perf/core] perf_events: " tip-bot for Frederic Weisbecker 2009-11-24 20:48 ` [PATCH] perf: " Peter Zijlstra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4B0BA99D.5020602@cn.fujitsu.com \ --to=lizf@cn.fujitsu.com \ --cc=eduard.munteanu@linux360.ro \ --cc=fweisbec@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mingo@elte.hu \ --cc=penberg@cs.helsinki.fi \ --cc=peterz@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.