Message-ID: <ZPusXvZwduHfxNnC@google.com>
Date:   Fri, 8 Sep 2023 16:21:02 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Nicolas Schier <nicolas@...sle.eu>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] scripts/setlocalversion: also consider annotated tags
 of the form vx.y.z-${file_localversion}

On Sat, Sep 09, 2023, Rasmus Villemoes wrote:
> On 08/09/2023 20.19, Sean Christopherson wrote:
> > On Fri, Aug 04, 2023, Rasmus Villemoes wrote:
> >> obviously asks if $tag is an annotated tag, but it does not actually
> >> tell if the commit pointed to has any relation to HEAD. So remove both
> >> uses of --exact-match, and instead just ask if the description
> >> generated is identical to the tag we provided. Since we then already
> >> have the result of
> >>
> >>   git describe --match=$tag
> >>
> >> we also end up reducing the number of times we invoke "git describe".
> > 
> > Dropping "--exact-match" is resulting in unnacceptable latencies for me.  I don't
> > understand what this is trying to do well enough to make a suggestion, but something
> > has to change.
> 
> Hm, that's quite unexpected. I mean, before that commit, I think that
> setlocalversion, especially when run on some dev branch, would _also_
> end up doing at least one 'git describe --match=v6.5'. <goes digging>
> 
> Ah, so I assume that in your case you always end up in the
> 
>                 # If only the short version is requested, don't bother
>                 # running further git commands
>                 if $short; then
>                         echo "+"
>                         return
>                 fi
> 
> case, i.e. you do not have CONFIG_LOCALVERSION_AUTO=y. Can you confirm that?

Yep, the configs I build most frequently have CONFIG_LOCALVERSION_AUTO=n, and
I can induce the bad behavior before this patch by toggling that on.

> > E.g. on my build box, a single `git describe --match=v6.5` takes ~8.5 seconds,
> 
> That's a long time indeed. I don't really know why it can take that long.

I can't figure that either.  It's not always slow, just almost always slow.  I
assume it has something to do with the number of commits/objects/merges git has
to trawl through, but I don't fully understand the behavior.

E.g. if I do `git describe --match=v6.5-rc2` on a branch based on v6.5-rc2, it's
basically instant.  But if take that same branch and merge it on top of v6.5,
`git describe --match=v6.5` takes 8.5 seconds even though the number of delta
commits is only one higher.

> > whereas a complete from-scratch kernel build takes <30 seconds, and an incremental
> > build takes <2 seconds.  When build testing to-be-applied changes, I compile each
> > commit ~15 times (different x86 configs plus one for each other KVM architecture),
> > which makes the ~8.5 second delay beyond painful.
> 
> Sorry about that. I agree something needs to be done, but the commit
> above fixed a real problem with -rt kernels, and the refactoring just
> made it much easier to follow the logic IMO - and, for the
> CONFIG_LOCALVERSION_AUTO=y case, did reduce the number of times git
> describe gets invoked.
> 
> Until I have a bit more time to think, could you try setting the env var
> LOCALVERSION when building - it can be set to anything, including empty.
> Then if I'm reading the script right, the scm_version() function won't
> be called at all.

Nice!  That does the trick.  Adding a useful LOCALVERSION is trivially easy for
all my builds, and as a bonus it's useful info for my test kernels.

So unless other people complain, I'm totally ok to leave this alone and not spend
any more time on it.

Thanks much!

Powered by blists - more mailing lists