[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMO-S2gyzK3VTQcTRw+FAO9ui_gy=1z=MVxUYM9sPN51KrDgkg@mail.gmail.com>
Date: Sun, 20 May 2012 18:37:57 +0900
From: Hitoshi Mitake <h.mitake@...il.com>
To: Darren Hart <dvhart@...ux.intel.com>
Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Paul Mackerras <paulus@...ba.org>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Michel Lespinasse <walken@...gle.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH] perf bench: add new benchmark subsystem and suite "futex wait"
On Sun, May 20, 2012 at 5:32 PM, Hitoshi Mitake <h.mitake@...il.com> wrote:
> On Fri, May 18, 2012 at 1:24 AM, Darren Hart <dvhart@...ux.intel.com> wrote:
>> On 05/17/2012 08:21 AM, Hitoshi Mitake wrote:
>>> Hi Ingo, Eric and Darren,
>>> (CCed perf and futex folks)
>>>
>>> I wrote this patch for adding new subsystem "futex" and its suite "wait" to perf
>>> bench on tip/master. This is based on futextest by Darren Hart.
>>>
>>> Could you allow me to import your source code of futextest to perf bench, Darren?
>>>
>>
>> I do have some concerns I'd like to address first.
>>
>> What is advantage of incorporating this into perf as opposed to running
>> it with perf?
>
> The main and direct advantage is that perf bench can share useful
> utilities stored under tools/perf/util/ directory e.g. parse-options[ch].
>
BTW, I often feel parse-options.[ch] of perf (this was come from git,
right?) is very useful not only for perf and git but also other
projects. So I think these stuff are worth independence as a
library. If the library contains unified feature for parsing and
evaluating configuration files, the hell of managing configurable
options will be reduced. e.g. I often use "strace -e open <command>"
to detect configuration files read by the <command>...
I thought that if perf bench can be independent from perf with such
efforts, it can be smaller sized and statically linked binary. From my
experience, this will be good for embedded systems people.
This independence also has risk: less people can find it or is
attracted even if it stays in the kernel tree (e.g. tools/bench/). But
it seems that very few people know about perf bench, so this will not
be a serious problem ;)
I'd like to hear your opinion.
Thanks,
--
Hitoshi Mitake
h.mitake@...il.com
--
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