From: John Garry <john.garry@huawei.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>
Cc: Ian Rogers <irogers@google.com>, Jiri Olsa <jolsa@kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
<linux-perf-users@vger.kernel.org>
Subject: Re: perf version issues
Date: Thu, 24 Mar 2022 17:09:54 +0000 [thread overview]
Message-ID: <85891cbd-e53c-89ac-6da2-40b5d56cd316@huawei.com> (raw)
In-Reply-To: <d3829e58-a835-eeec-e1a5-d282a610b228@huawei.com>
+ Ingo
On 23/03/2022 12:44, John Garry wrote:
>> $ git cherry-pick cb66befccba18fac
>> [perf/core 8ff6a6c06a90a362] perf tools: Fix version kernel tag
>> Author: John Garry<john.garry@huawei.com>
>> Date: Mon Feb 21 21:16:49 2022 +0800
>> 1 file changed, 4 insertions(+), 9 deletions(-)
>> $ make -C tools/perf O=/tmp/build/perf install-bin
>> $ perf -v
>> perf version 5.17.rc8.g4e666cdb06ee
>>
>> Now it doesn´t notice it and there is no automatic rebuild triggered, we
>> stay with the cset from before the cherry-pick:-\
>>
>> $ git log --oneline -2
>> 8ff6a6c06a90a362 (HEAD -> perf/core) perf tools: Fix version kernel tag
>> 4e666cdb06eede20 perf tools: Fix dependency for version file creation
>> $
>>
>> Anyway, your patch works for some cases, so its an improvement and I'll
>> apply it, we can continue from there.
>
> After some experimentation, I find that only .git/HEAD changes for a
> cherry-pick depending on whether we're on a branch or not. As such, as
> you have seen, we may not rebuild after a cherry-pick, which is no good.
>
> As far as I can see, only .git/index changes in all circumstances, but
> we don't have a dependency on that.
>
> TBH, using .git files as Makefile dependencies doesn't seem to work well.
>
> Maybe we should output "git log" and check versus what we have in
> PERF-VERSION-FILE and re-build depending on that.
>
> Let me check this further now.
Just an update on this...
I did some research and found that Ingo introduced the change to make
.git/HEAD a dependency as a build optimisation. See commit commit
c72e3f04b45fb2e50cdd81a50c3778c6a57251d8 ("tools/perf/build: Speed up
git-version test on re-make")
According to the commit log it's quicker to trigger a rebuild of the
version string depending on a change in a git internal file rather than
run "git describe" to see any change in tag/commit every times.
However, I asked the git community about this approach, and their
general idea is that a dependency on .git/HEAD or other git internal
file is just not a good idea.
See
https://lore.kernel.org/git/87wngkpddp.fsf@igel.home/T/#m4a4dd6de52fdbe21179306cd57b3761eb07f45f8
So to get this working robustly we may need to roll back that named
commit in part.
Thanks,
John
prev parent reply other threads:[~2022-03-24 17:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8a75f3b1-2b99-1233-3a70-070311b6ebc1@huawei.com>
2022-03-22 20:11 ` perf version issues Arnaldo Carvalho de Melo
2022-03-22 22:17 ` John Garry
2022-03-23 12:44 ` John Garry
2022-03-24 17:09 ` John Garry [this message]
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=85891cbd-e53c-89ac-6da2-40b5d56cd316@huawei.com \
--to=john.garry@huawei.com \
--cc=acme@kernel.org \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.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 NNTP newsgroup(s).