Re: [PATCH] cpumask: Switch from inline to __always_inline

[Brian Norris <briannorris@chromium.org>]

Hi Yury, Nathan,

On Wed, Jul 03, 2024 at 12:57:24PM -0700, Nathan Chancellor wrote:
> On Wed, Jul 03, 2024 at 12:06:36PM -0700, Yury Norov wrote:
> > On Tue, Jun 25, 2024 at 11:27:59AM -0700, Brian Norris wrote:
> > > On Tue, May 14, 2024 at 01:49:01PM -0700, Brian Norris wrote:
> > > > This change (plus more) has been previously proposed for other reasons
> > > > -- that some of the bitmask 'const' machinery doesn't work without
> > > > inlining -- in the past as:
> > > > 
> > > >   Subject: [PATCH 1/3] bitmap: switch from inline to __always_inline
> > > >   https://lore.kernel.org/all/20221027043810.350460-2-yury.norov@gmail.com/
> > > > 
> > > > It seems like a good idea to at least make all cpumask functions use
> > > > __always_inline; several already do.
> 
> > I feel that if we decide making cpumask an __always_inline is the
> > right way, we also should make underlying bitmap API __always_inline
> > just as well. Otherwise, there will be a chance of having outlined
> > bitmap helpers, which may confuse clang again.
> 
> If this does not result in noticeable bloat, this may not be a bad
> idea. I seem to recall this being an issue in the past for us but I
> cannot seem to find the issue at this point. Commit 1dc01abad654
> ("cpumask: Always inline helpers which use bit manipulation functions")
> comes to mind.

In the above quote, I already referenced Yury's previous post to do just
that (__always_inline for all of bitmask and cpumask). I don't know why
that wasn't ever merged, so I instead chose a smaller set that resolved
my current problems.

I can dust that off, rebase it, and give it a bloat check if that's
preferable though.

Brian