Re: [PATCH v2] scripts/setlocalversion: also consider annotated tags of the form vx.y.z-${file_localversion}

[Sean Christopherson <seanjc@google.com>]

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!