From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27839 invoked by alias); 24 Dec 2013 06:51:44 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 27822 invoked by uid 89); 24 Dec 2013 06:51:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail7.hitachi.co.jp Received: from mail7.hitachi.co.jp (HELO mail7.hitachi.co.jp) (133.145.228.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Dec 2013 06:51:42 +0000 Received: from mlsv3.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 58CFE37AC6; Tue, 24 Dec 2013 15:51:39 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv3.hitachi.co.jp (8.13.1/8.13.1) id rBO6pdIe025902; Tue, 24 Dec 2013 15:51:39 +0900 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id rBO6pZjR012114; Tue, 24 Dec 2013 15:51:38 +0900 Received: from gxml20a.ad.clb.hitachi.co.jp (unknown [158.213.157.160]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 080CE140057; Tue, 24 Dec 2013 15:51:38 +0900 (JST) Received: from [10.198.214.92] by gxml20a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 5BO63F1G200002F8C; Tue, 24 Dec 2013 15:51:37 +0900 Message-ID: <52B92EEE.2020803@hitachi.com> Date: Tue, 24 Dec 2013 06:51:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Arnaldo Carvalho de Melo Cc: Ingo Molnar , Srikar Dronamraju , David Ahern , lkml , "Steven Rostedt (Red Hat)" , Oleg Nesterov , "David A. Long" , systemtap@sourceware.org, yrl.pp-manager.tt@hitachi.com, Namhyung Kim Subject: Re: [PATCH -tip 1/3] [CLEANUP] perf-probe: Expand given path to absolute path References: <20131220100255.7169.19384.stgit@kbuild-fedora.novalocal> <20131220100257.7169.60537.stgit@kbuild-fedora.novalocal> <20131220180031.GA28878@ghostprotocols.net> <52B75B0D.6010401@hitachi.com> <20131223142832.GF28878@ghostprotocols.net> In-Reply-To: <20131223142832.GF28878@ghostprotocols.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00497.txt.bz2 (2013/12/23 23:28), Arnaldo Carvalho de Melo wrote: > Em Mon, Dec 23, 2013 at 06:35:09AM +0900, Masami Hiramatsu escreveu: >> (2013/12/21 3:00), Arnaldo Carvalho de Melo wrote: >>> Em Fri, Dec 20, 2013 at 10:02:57AM +0000, Masami Hiramatsu escreveu: >>>> Expand given path to absolute path in option parser, >>>> except for a module name. Instead of expanding it later, >>>> this get the absolute path in early stage. >>> >>> What is the problem this solves? >>> >>> Can you provide some output showing the problem, i.e. before you apply >>> this patch? >> >> No, this is just a code cleanup, for the later enhancements. > > Ok, this is just a cleanup, but what does this cleanup achieves? Why is > it better to "getting the absolute path in early stage"? > > I.e. you're describing what the patch does, and I can see it from > reading code, but why is it good to do it in an early stage? --- Since realpath at the later stage in processing several probe point can be called several times(even if currently doesn't, it can happen when we expands the feature), it is waste of the performance. Processing it once at the early stage can avoid that. --- Is that good enough for you? :) > >> Should I put it into the next patch? > > No need for that, just, please, clarify why it is needed. > OK, I'll do that:) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com