Re: [PATCH] mm: avoid use of BIT() macro for initialising VMA flags

[Mateusz Guzik <mjguzik@gmail.com>]

So I had a look where the timing difference is coming from and I think
I have the answer: init_ipc_ns does not have a guaranteed cacheline
placement and things get moved around with the patch.

On my kernels (nm vmlinux-newbits | sort -nk 1 | less)

before:
ffffffff839ffb60 T init_ipc_ns
ffffffff83a00020 t event_exit__msgrcv

after:
ffffffff839ffbc0 T init_ipc_ns
ffffffff83a00080 t event_exit__msgrcv

This is the pervasive problem of vars from all .o files placed
adjacent to each other, meaning changes in one .o file result in
offsets changing in other files and then you get performance
fluctuations as not-explicitly-padded variables share (or no longer
share) cachelines.

I brought this up a year ago elsewhere:
https://gcc.gnu.org/pipermail/gcc/2024-October/245004.html

maybe i should pick it up again and see it through

as for the thing at hand, someone(tm) will want to make sure the
namespace is cacheline aligned and possibly pad its own internals
afterwards. Personally I can't be bothered.