[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091109075512.GG453@elte.hu>
Date: Mon, 9 Nov 2009 08:55:12 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Cc: linux-kernel@...r.kernel.org, rusty@...tcorp.com.au,
tglx@...utronix.de, a.p.zijlstra@...llo.nl, efault@....de,
acme@...hat.com, fweisbec@...il.com
Subject: Re: [PATCH v2 3/7] Adding general performance benchmarking
subcommand to perf.
* Hitoshi Mitake <mitake@....info.waseda.ac.jp> wrote:
> From: Ingo Molnar <mingo@...e.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
--
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