All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: linux-kernel@vger.kernel.org, rusty@rustcorp.com.au,
	tglx@linutronix.de, a.p.zijlstra@chello.nl, efault@gmx.de,
	acme@redhat.com, fweisbec@gmail.com
Subject: Re: [PATCH v2 3/7] Adding general performance benchmarking subcommand to perf.
Date: Tue, 10 Nov 2009 06:19:01 +0100	[thread overview]
Message-ID: <20091110051901.GI7897@elte.hu> (raw)
In-Reply-To: <20091110.015023.244106360.mitake@dcl.info.waseda.ac.jp>


* Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Subject: Re: [PATCH v2 3/7] Adding general performance benchmarking subcommand to perf.
> Date: Mon, 9 Nov 2009 08:55:12 +0100
> 
> > 
> > * Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> wrote:
> > 
> > > From: Ingo Molnar <mingo@elte.hu>
> > > Subject: Re: [PATCH v2 3/7] Adding general performance benchmarking subcommand to perf.
> > > Date: Sun, 8 Nov 2009 12:30:13 +0100
> > > 
> > > > > > 
> > > > > > Shouldnt we output the unit of measurement, i.e. '4.575 usecs'? Also, we 
> > > > > > should perhaps print something like:
> > > > > > 
> > > > > >   % perf bench sched pipe
> > > > > > 
> > > > > >   (executing 1000000 pipe operations between two tasks)
> > > > > > 
> > > > > >      4.575 usecs per op
> > > > > >     218579 ops/sec   
> > > > > > 
> > > > > > ?
> > > > > 
> > > > > I have to admit that single float value output is too simple.
> > > > > So I'll fix the default output.
> > > > > 
> > > > > But, I believe that simple form makes sense for
> > > > > processing by scripts or graph tools like gnuplot.
> > > > > I'll add the option (may be --simple) to switch
> > > > > friendliness of outputs.
> > > > 
> > > > Btw., could you make it Git-ish, i.e.:
> > > > 
> > > >  --format=short
> > > > 
> > > > or:
> > > > 
> > > >  --format=simple
> > > > 
> > > > Eventually more format options might be added.
> > > 
> > > It's good idea.
> > > I have to admit that reserving -s for simple output is not good idea.
> > > I'll do this.
> > 
> > I think --format=simple will be used by scripts mostly, so it doesnt 
> > matter that it's longer to type. We try to save the shorter options for 
> > humans and be conservative with them.
> > 
> > Another angle is coherency between different subcommands - and '-s' is 
> > already used as -s/--sort in other perf subcommands, which does not 
> > match up with the '-s/--simple' usage.
> > 
> > We try to match what the Git project does here - a good deal of 
> > infrastructure code in perf came from Git and i find Git very easy to 
> > use and it's managed well.
> > 
> > It's not a hard rule: not all option name incoherencies are fixable or 
> > avoidable, and there's no big problem if something slips in - i just 
> > wanted to mention so that you can keep an eye on it when developing new 
> > features for perf bench.
> > 
> > 	Ingo
> > 
> 
> I added --format as option of bench subcommand,
> not of each suites.
> Because I thought that flavors of formatting are common thing
> across the suites.

yeah. Maybe it might be librarized into util/ as well in the future, if 
another perf subcommand wants to pick it up.

> 
> Example of use:
> % ./perf bench sched pipe           # with no style specify
> (executing 1000000 pipe operations between two tasks)
> 
>         Total time:5.855 sec
>                 5.855061 usecs/op
>                 170792 ops/sec
> % ./perf bench --format=simple sched pipe # specified simple
>                ^^^^^^^^^^^^^^^	# <- --format is here
> 5.988
> 
> How do you think?
> I'll send patch series later.

Looks good - i picked them up.

Thanks,

	Ingo

      reply	other threads:[~2009-11-10  5:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03 10:55 [PATCH v2 3/7] Adding general performance benchmarking subcommand to perf Hitoshi Mitake
2009-11-03 17:29 ` Ingo Molnar
2009-11-04 10:41   ` Hitoshi Mitake
2009-11-08 11:30     ` Ingo Molnar
2009-11-09  3:27       ` Hitoshi Mitake
2009-11-09  7:55         ` Ingo Molnar
2009-11-09 16:50           ` Hitoshi Mitake
2009-11-10  5:19             ` Ingo Molnar [this message]

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=20091110051901.GI7897@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=efault@gmx.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mitake@dcl.info.waseda.ac.jp \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    /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: link
Be 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.