From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Paul Mackerras <paulus@samba.org>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>, Borislav Petkov <bp@suse.de>,
Hemant Kumar <hemant@linux.vnet.ibm.com>
Subject: Re: Re: [perf/core PATCH v2 3/4] perf buildid-cache: Add new buildid cache if update target is not cached
Date: Thu, 12 Feb 2015 15:36:58 +0900 [thread overview]
Message-ID: <54DC4A0A.8030709@hitachi.com> (raw)
In-Reply-To: <20150211145742.GI24251@kernel.org>
(2015/02/11 23:57), Arnaldo Carvalho de Melo wrote:
> Em Wed, Feb 11, 2015 at 11:49:28AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Feb 10, 2015 at 06:18:56PM +0900, Masami Hiramatsu escreveu:
>>> Add new buildid cache if the update target file is not cached.
>>> This can happen when an old binary is replaced by new one
>>> after caching the old one. In this case, user sees his operation
>>> just failed. But it does not look straight, since user just
>>> pass the binary "path", not "build-id".
>>>
>>> ----
>>> # ./perf buildid-cache --add ./perf
>>> (update ./perf to new binary)
>>> # ./perf buildid-cache --update ./perf
>>> ./perf wasn't in the cache
>>
>> Humm, without re-reading the original motivation for the '--update'
>> operation I would think it was about finding all build-ids in the cache
>> that are for a binary with that path, remove them and insert this new
>> one, no?
>>
>> Checking...
>
> commit eeb49845425375481f14c0e5721f88242642e88e
> Author: Namhyung Kim <namhyung.kim@lge.com>
> Date: Thu Feb 7 18:02:11 2013 +0900
>
> perf buildid-cache: Add --update option
>
> When adding vmlinux file to build-id cache, it'd be fail since kallsyms
> dso with a same build-id was already added by perf record.
>
> So one needs to remove the kallsyms first to add vmlinux into the cache.
> Add --update option for doing it at once.
>
> ----------------------------------------------------------------------------------
>
> So this was really a 'remove the file that is pointed by this build-id' and
> replace with this new file, i.e. there is both a vmlinux _and_ a kallsyms file
> for the same build-id. When wanting to use one or the other and existing a
> link in the cache, one uses this --update thing.
>
> That is ok for cases where there are multiple symtabs in the cache for a given
> build-id, but as you mention above, it is confusing for updating by _pathname_.
>
> What a 'update' by pathname would mean? I guess it would be to remove 'old',
> i.e. 'not up-to-date' stuff, i.e. older build-ids that that pathname had in the
> past, and leave just this new stuff.
>
> The way you did it make '--update path' be equivalent to '--add path'.
Right, if there is no same buildid cache, it does that.
Actually, this is a kind of middle point solution. As far as I can see,
buildid-cache is (currently) used for annotating the old, or remote perf.data.
In that case, we may have several different versions of buildid-cache(binaries)
for one pathname. If --update destructively updates all caches related to
given pathname, it also means to loose annotatability(?) on old or remote
perf.data. I think that may not the user wants.
So, if user really wants to clean up their cache, he/she can use --purge
(--remove-all).
And I think it would be better that --update just adds given current binary
to cache if there is no cache.
Thank you,
>
> - Arnaldo
> --
> 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/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2015-02-12 6:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 9:18 [perf/core PATCH v2 0/4] perf-buildid-cache: Cleanup, enhance --update and add --remove-all Masami Hiramatsu
2015-02-10 9:18 ` [perf/core PATCH v2 1/4] perf-buildid-cache: Remove unneeded debugdir parameters Masami Hiramatsu
2015-02-18 18:29 ` [tip:perf/core] perf buildid-cache: " tip-bot for Masami Hiramatsu
2015-02-10 9:18 ` [perf/core PATCH v2 2/4] perf buildid-cache: Consolidate .build-id cache path generators Masami Hiramatsu
2015-02-11 14:46 ` Arnaldo Carvalho de Melo
2015-02-18 18:30 ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2015-02-10 9:18 ` [perf/core PATCH v2 3/4] perf buildid-cache: Add new buildid cache if update target is not cached Masami Hiramatsu
2015-02-11 14:49 ` Arnaldo Carvalho de Melo
2015-02-11 14:57 ` Arnaldo Carvalho de Melo
2015-02-12 6:36 ` Masami Hiramatsu [this message]
2015-02-12 14:11 ` Arnaldo Carvalho de Melo
2015-02-10 9:18 ` [perf/core PATCH v2 4/4] perf buildid-cache: Add --remove-all FILE to remove all caches of FILE Masami Hiramatsu
2015-02-11 15:00 ` Arnaldo Carvalho de Melo
2015-02-12 6:13 ` Masami Hiramatsu
2015-02-12 14:12 ` Arnaldo Carvalho de Melo
2015-02-10 14:09 ` [perf/core PATCH v2 0/4] perf-buildid-cache: Cleanup, enhance --update and add --remove-all Namhyung Kim
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=54DC4A0A.8030709@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=bp@suse.de \
--cc=hemant@linux.vnet.ibm.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
/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.