public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	       Hemant Kumar <hemant@linux.vnet.ibm.com>,
	       Namhyung Kim <namhyung@kernel.org>,
	       "linux-kernel@vger.kernel.org"
	<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: [RFC] perf-cache command interface design
Date: Mon, 10 Nov 2014 12:31:00 -0000	[thread overview]
Message-ID: <20141110123131.GD4468@redhat.com> (raw)
In-Reply-To: <CAPh34mfj5DJSbUBhQSZS_QpTUubV5a7UEsiyzfNSia3bjU2kww@mail.gmail.com>

Em Mon, Nov 10, 2014 at 01:05:45PM +0100, Hagen Paul Pfeifer escreveu:
> On 7 November 2014 09:21, Masami Hiramatsu
> <masami.hiramatsu.pt@hitachi.com> wrote:
> 
> > File Format
> > ===========
> > All the cache files are placed under ~/.debug/ by default.
> > The paths of buildid cache of binary/symbols are not changed.
> >
> > The SDT/probe caches are placed under the ~/.debug/.probes/path/to/bin/bu/ildid
> > and that is linked to ~/.debug/.probes/.buildid/bu/ildid
> > # To avoid conflict with files under /probes/*, I picked up .probes/.
> 
> A little bit late: but why ~/.debug? Why not $XDG_CACHE_HOME/perf/ as

Why "perf"?

> the root for all perf related files? debug is not unique nor is it sufficient

Probably should be some other name then, but ~/.debug/ is there since
the build-id cache was introduced, guess this is why it is being kept so
far in Masami's proposal.

> to meet file hierarchy: man file-hierarchy(8)

Humm,

It starts in $HOME/.debug/ because this is not supposed to be a system
wide cache, a developer can, for instance:

1. perf record myapp
2. edit myapp.c
3. rebuild it
4. perf record myapp
5. perf diff

And it will show the difference from the previous version, for which it
stored a copy of its binary on its private, keyed by build-id, cache.

So this is not merely a place where we will read stuff from.

If somebody decides to have it in a place accessible by multiple users
on the same system, then, yes, some more suitable place outside its
$HOME is needed, and then tooling should look there as well as on the
places it already looks for such files, i.e. $HOME/.debug/,
/usr/lib/debug (where foo-debuginfo packages store stuff, also keyed by
build-id), /lib/modules/$KVR/, etc.

- Arnaldo

  reply	other threads:[~2014-11-10 12:31 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02 12:40 [PATCH v4 0/5] perf/sdt: SDT events listing/probing Hemant Kumar
2014-11-02 12:41 ` [PATCH v4 1/5] perf/sdt: ELF support for SDT Hemant Kumar
2014-11-02 12:42 ` [PATCH v4 3/5] perf/sdt: Show SDT cache contents Hemant Kumar
2014-11-02 12:42 ` [PATCH v4 4/5] perf/sdt: Delete SDT events from cache Hemant Kumar
2014-11-02 12:42 ` [PATCH v4 2/5] perf/sdt: Add SDT events into a cache Hemant Kumar
2014-11-02 12:43 ` [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:57       ` Masami Hiramatsu
     [not found]         ` <5459BD3E.7010804@linux.vnet.ibm.com>
2014-11-05  6:51           ` 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:16             ` Josh Stone
2014-11-06  5:34               ` 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:58                   ` [PATCH RESEND 1/2] perf tools: Move disable_buildid_cache() to util/build-id.c Namhyung Kim
2014-11-07 13:58                     ` [PATCH 2/2] perf tools: Add record.use-buildid-cache config option 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:26                         ` Masami Hiramatsu
2014-11-17  3:09                           ` 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
2014-11-17 18:59                             ` Arnaldo Carvalho de Melo
2014-11-18  4:46                               ` Namhyung Kim
2014-11-10 12:05                 ` Hagen Paul Pfeifer
2014-11-10 12:31                   ` Arnaldo Carvalho de Melo [this message]
2014-11-10 12:50                   ` Peter Zijlstra
2014-11-10 13:37                     ` Hagen Paul Pfeifer
2014-11-05 18:24           ` [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=20141110123131.GD4468@redhat.com \
    --to=acme@redhat.com \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=brendan.d.gregg@gmail.com \
    --cc=hagen@jauu.net \
    --cc=hegdevasant@linux.vnet.ibm.com \
    --cc=hemant@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).