Re: [linux-next:master] [mm] 2b6a3f061f: stress-ng.msg.ops_per_sec 34.1% regression

On Fri, Dec 05, 2025 at 02:33:08PM +0000, Lorenzo Stoakes wrote:
> On Fri, Dec 05, 2025 at 12:11:23PM +0000, Lorenzo Stoakes wrote:
> > On Fri, Dec 05, 2025 at 09:41:37AM +0800, kernel test robot wrote:
> > >
> > >
> > > Hello,
> > >
> > > kernel test robot noticed a 34.1% regression of stress-ng.msg.ops_per_sec on:
> > >
> > >
> > > commit: 2b6a3f061f11372af79b862d6184d43193ae927f ("mm: declare VMA flags by bit")
> >
> > This is strange, as this _should_ have no actual impact on anything.
> >
> > However, it seems that <= 32-bit flags being declared as de-facto unsigned int
> > is the delta here, and by declaring everything as an unsigned long via BIT() we
> > have inadvertantly undone this optimisation.
> >
> > We can resolve this by having two types of INIT_VM_FLAG() macro - one for 32-bit
> > flags and one for 64-bit flags and using each as appropriate.
> >
> > I will send a patch shortly.
> >
> > Cheers, Lorenzo
>
> OK, having said that, I've now been able to restore original performance to
> baseline just by making the result signed rather than unsigned :/
>
> I am digging in to why on earth this is the case, will see if I can figure out
> which flag and then which bit of code is somehow relying on this.
>
> BTW I notice reduced system time before patch/with fixup, but the actual bogo
> ops/s values are... worse before + after the patch cited as a regression here?

OK it's not even this :) it's the fact that _somehow_ the BIT() macro does
something funky which causes some imperfect macro expansion somewhere (due to
the (__force int) case). Good lord.

Patch incoming in a second.

Cheers, Lorenzo