Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756012Ab2FESSg (ORCPT ); Tue, 5 Jun 2012 14:18:36 -0400 Received: from mga03.intel.com ([143.182.124.21]:43543 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754565Ab2FESSf (ORCPT ); Tue, 5 Jun 2012 14:18:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108170825" Message-ID: <4FCE4D24.5040307@linux.intel.com> Date: Tue, 05 Jun 2012 11:17:08 -0700 From: Darren Hart User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hitoshi Mitake CC: Ingo Molnar , linux-kernel@vger.kernel.org, Peter Zijlstra , Paul Mackerras , Arnaldo Carvalho de Melo , Michel Lespinasse , Rusty Russell , Eric Dumazet Subject: Re: [PATCH] perf bench: add new benchmark subsystem and suite "futex wait" References: <1337268092-6765-1-git-send-email-h.mitake@gmail.com> <4FB52636.3040604@linux.intel.com>

In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2352 Lines: 56 On 05/20/2012 02:37 AM, Hitoshi Mitake wrote: > On Sun, May 20, 2012 at 5:32 PM, Hitoshi Mitake wrote: >> On Fri, May 18, 2012 at 1:24 AM, Darren Hart 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 " > to detect configuration files read by the ... > > 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. I haven't been involved with perf tools/bench so I haven't really formed an opinion. Ingo and Arnaldo, would either of you care to weigh in on the pros/cons of merging futextest into perf? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/