All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	Hemant Kumar <hemant@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, srikar@linux.vnet.ibm.com,
	peterz@infradead.org, oleg@redhat.com,
	hegdevasant@linux.vnet.ibm.com, mingo@redhat.com,
	systemtap@sourceware.org, aravinda@linux.vnet.ibm.com,
	penberg@iki.fi, brendan.d.gregg@gmail.com,
	"yrl.pp-manager.tt@hitachi.com" <yrl.pp-manager.tt@hitachi.com>
Subject: Re: Re: [RFC] perf-cache command interface design
Date: Tue, 18 Nov 2014 19:32:21 +0900	[thread overview]
Message-ID: <546B2035.2060402@hitachi.com> (raw)
In-Reply-To: <87389hruhn.fsf@sejong.aot.lge.com>

(2014/11/18 13:41), Namhyung Kim wrote:
> Hi Masami,
> 
> On Mon, 17 Nov 2014 12:17:31 +0900, Masami Hiramatsu wrote:
>> (2014/11/17 12:08), Namhyung Kim wrote:
>>> I prefer this too.  But I'd like make the 'add' part a subcommand rather
>>> than option like we do in perf kmem/kvm/list/lock/mem/sched ...  And it
>>> can handle multiple files at once.  What about this?
>>>
>>>   perf cache add [--elf|--sdt|--probe <spec>] <binary> [<binary>...]
>>
>> OK, that's good to me. And I think --elf/--sdt is meaningless.
> 
> Maybe not :)
> 
> I'm considering the opposite side - by providing the options, we also
> support the negative ones too.  So --no-elf and/or --no-sdt options are
> possible.  Also the positive options can be used with del(ete)
> subcommand to remove some contents selectively.
> 
> I think it'd be helpful as we sometimes don't want to do that for some
> reason.  For example, current perf record adds binary (elf) files to the
> cache automatically iff it's accessed.  But what about SDTs?  Should we
> add SDTs at the same time?  If not, what if we try to add existing elf
> files only for SDTs?

Ah, I see. Indeed, in this case we'd better have perf cache add --sdt <bin>
for explicitly adding SDTs. (Of course perf cache add <bin> can also
add SDTs automagically, but adding --sdt is more natural)

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com



  reply	other threads:[~2014-11-18 10:32 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02 10:53 [PATCH v4 0/5] perf/sdt: SDT events listing/probing Hemant Kumar
2014-11-02 10:54 ` [PATCH v4 1/5] perf/sdt: ELF support for SDT Hemant Kumar
2014-11-02 10:54 ` [PATCH v4 2/5] perf/sdt: Add SDT events into a cache Hemant Kumar
2014-11-02 10:55 ` [PATCH v4 3/5] perf/sdt: Show SDT cache contents Hemant Kumar
2014-11-02 10:55 ` [PATCH v4 4/5] perf/sdt: Delete SDT events from cache Hemant Kumar
2014-11-02 10:56 ` [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events Hemant Kumar
2014-11-04  7:38   ` Namhyung Kim
2014-11-04  8:06     ` Hemant Kumar
2014-11-04 12:56       ` Masami Hiramatsu
     [not found]         ` <5459BD3E.7010804@linux.vnet.ibm.com>
2014-11-05  6:50           ` Hemant Kumar
2014-11-05  9:07             ` Masami Hiramatsu
2014-11-05 13:28               ` Arnaldo Carvalho de Melo
2014-11-05  7:06         ` Namhyung Kim
2014-11-05  9:05           ` Masami Hiramatsu
2014-11-06  2:15             ` Josh Stone
2014-11-06  5:33               ` Masami Hiramatsu
2014-11-06  7:06             ` Hemant Kumar
2014-11-06 14:56               ` Masami Hiramatsu
2014-11-07  8:21               ` [RFC] perf-cache command interface design Masami Hiramatsu
2014-11-07  8:42                 ` Peter Zijlstra
2014-11-07 13:57                   ` [PATCH RESEND 1/2] perf tools: Move disable_buildid_cache() to util/build-id.c Namhyung Kim
2014-11-07 13:57                     ` [PATCH 2/2] perf tools: Add record.use-buildid-cache config option Namhyung Kim
2014-11-20  7:36                     ` [tip:perf/core] perf build-id: Move disable_buildid_cache() to util/build-id.c tip-bot for Namhyung Kim
2014-11-07 15:16                   ` [RFC] perf-cache command interface design David Ahern
2014-11-07 15:33                     ` Arnaldo Carvalho de Melo
2014-11-07 10:51                 ` Hemant Kumar
2014-11-08  4:15                   ` Masami Hiramatsu
2014-11-07 14:38                 ` Arnaldo Carvalho de Melo
2014-11-08  4:26                   ` Masami Hiramatsu
2014-11-07 14:43                 ` Namhyung Kim
2014-11-08  4:38                   ` Masami Hiramatsu
2014-11-10 10:59                 ` Masami Hiramatsu
2014-11-10 12:23                   ` Arnaldo Carvalho de Melo
2014-11-11  6:53                     ` Masami Hiramatsu
2014-11-11 13:10                       ` Arnaldo Carvalho de Melo
2014-11-12 15:25                         ` Masami Hiramatsu
2014-11-17  3:08                           ` Namhyung Kim
2014-11-17  3:17                             ` Masami Hiramatsu
2014-11-17 22:09                               ` Masami Hiramatsu
2014-11-18  4:51                                 ` Namhyung Kim
2014-11-18 11:16                                   ` Masami Hiramatsu
2014-11-18  4:41                               ` Namhyung Kim
2014-11-18 10:32                                 ` Masami Hiramatsu [this message]
2014-11-17 18:58                             ` Arnaldo Carvalho de Melo
2014-11-18  4:45                               ` Namhyung Kim
2014-11-10 12:05                 ` Hagen Paul Pfeifer
2014-11-10 12:31                   ` Arnaldo Carvalho de Melo
2014-11-10 12:50                   ` Peter Zijlstra
2014-11-10 13:37                     ` Hagen Paul Pfeifer
2014-11-05 18:23           ` [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events Hemant Kumar

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=546B2035.2060402@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=acme@redhat.com \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=brendan.d.gregg@gmail.com \
    --cc=hegdevasant@linux.vnet.ibm.com \
    --cc=hemant@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=oleg@redhat.com \
    --cc=penberg@iki.fi \
    --cc=peterz@infradead.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=systemtap@sourceware.org \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /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.