Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
Lorenzo Stoakes <[email protected]>
| Newsgroups | org.kernel.vger.linux-sgx,dev.linux.lists.ntfs3,dev.linux.lists.nvdimm,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.kernel.vger.keyrings,org.kernel.vger.linux-cxl,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-security-module,org.kernel.vger.linux-xfs,org.kvack.linux-mm,org.ozlabs.lists.linux-erofs |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Jan 20, 2026 at 05:44:29PM +0100, Arnd Bergmann wrote: > On Tue, Jan 20, 2026, at 17:22, Lorenzo Stoakes wrote: > > On Tue, Jan 20, 2026 at 05:00:28PM +0100, Arnd Bergmann wrote: > >> On Tue, Jan 20, 2026, at 16:10, Lorenzo Stoakes wrote: > >> > > >> > It strikes me that the key optimisation here is the inlining, now if the issue > >> > is that ye olde compiler might choose not to inline very small functions (seems > >> > unlikely) we could always throw in an __always_inline? > >> > >> I can think of three specific things going wrong with structures passed > >> by value: > > > > I mean now you seem to be talking about it _in general_ which, _in theory_, > > kills the whole concept of bitmap VMA flags _altogether_ really, or at > > least any workable version of them. > > No, what I'm saying is "understand what the pitfalls are", not > "don't do it". I think that is what Jason was also getting at. > > Arnd Ack sure and your input is appreciated :) It's important to kick the tyres and be aware of possible issues. Actually I think now I understand where Jason's coming from - the by-value cases will be const value for the most part - which should make life MUCH easier for the compiler and avoid a lot of the issues you raised. So _hopefully_ we're mitigated. Again as I said, in cases where we might not be, I will take action to figure out workarounds. I'm excited by the proposed approach in general (+ again thanks to Jason to opening my eyes to the possibility in the first place), so perhaps a _little_ defensive, as it allows for a like-for-like replacement generally which should HUGELY speed up + simplify the transition :) Cheers, Lorenzo