Message-ID: <44461883-a75c-466b-a278-97c4ab46b461@lucifer.local>
Date: Tue, 20 Jan 2026 16:22:14 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Jason Gunthorpe <jgg@...dia.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Dave Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tursulin@...ulin.net>,
        Christian König <christian.koenig@....com>,
        Huang Rui <ray.huang@....com>, Matthew Auld <matthew.auld@...el.com>,
        Matthew Brost <matthew.brost@...el.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Benjamin LaHaise <bcrl@...ck.org>, Gao Xiang <xiang@...nel.org>,
        Chao Yu <chao@...nel.org>, Yue Hu <zbestahu@...il.com>,
        Jeffle Xu <jefflexu@...ux.alibaba.com>,
        Sandeep Dhavale <dhavale@...gle.com>,
        Hongbo Li <lihongbo22@...wei.com>, Chunhai Guo <guochunhai@...o.com>,
        Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Muchun Song <muchun.song@...ux.dev>,
        Oscar Salvador <osalvador@...e.de>,
        "David Hildenbrand (Red Hat)" <david@...nel.org>,
        Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
        Mike Marshall <hubcap@...ibond.com>,
        Martin Brandenburg <martin@...ibond.com>,
        Tony Luck <tony.luck@...el.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Dave Martin <Dave.Martin@....com>, James Morse <james.morse@....com>,
        Babu Moger <babu.moger@....com>, Carlos Maiolino <cem@...nel.org>,
        Damien Le Moal <dlemoal@...nel.org>,
        Naohiro Aota <naohiro.aota@....com>,
        Johannes Thumshirn <jth@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Hugh Dickins <hughd@...gle.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>, Zi Yan <ziy@...dia.com>,
        Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
        Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
        Lance Yang <lance.yang@...ux.dev>, Jann Horn <jannh@...gle.com>,
        Pedro Falcato <pfalcato@...e.de>, David Howells <dhowells@...hat.com>,
        Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Yury Norov <yury.norov@...il.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>, linux-sgx@...r.kernel.org,
        linux-kernel@...r.kernel.org, nvdimm@...ts.linux.dev,
        linux-cxl@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        intel-gfx@...ts.freedesktop.org, linux-fsdevel@...r.kernel.org,
        linux-aio@...ck.org, linux-erofs@...ts.ozlabs.org,
        linux-ext4@...r.kernel.org, linux-mm@...ck.org, ntfs3@...ts.linux.dev,
        devel@...ts.orangefs.org, linux-xfs@...r.kernel.org,
        keyrings@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t
 only

On Tue, Jan 20, 2026 at 05:00:28PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 20, 2026, at 16:10, Lorenzo Stoakes wrote:
> > On Tue, Jan 20, 2026 at 09:36:19AM -0400, Jason Gunthorpe wrote:
> >
> > I am not sure about this 'idiomatic kernel style' thing either, it feels rather
> > conjured. Yes you wouldn't ordinarily pass something larger than a register size
> > by-value, but here the intent is for it to be inlined anyway right?
> >
> > 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.

But... no.

I'm not going to not do this because of perceived possible issues with ppc
and mips.

It's not reasonable to hold up a necessary change for the future of the
kernel IMO, and we can find workarounds as necessary should anything
problematic actually occur in practice.

I am happy to do so as maintainer of this work :)

>
> - functions that cannot be inlined are bound by the ELF ABI, and
>   several of them require structs to be passed on the stack regardless
>   of the size. Most of the popular architectures seem fine here, but
>   mips and powerpc look like they are affected.

I explicitly checked mips and it seemed fine, but not gone super deep.

>
> - The larger the struct is, the more architectures are affected.
>   Parts of the amdgpu driver and the bcachefs file system ran into this

bcachefs is not in the kernel. We don't care about out-of-tree stuff by
convention.

amdgpu is more concerning, but...

>   with 64-bit structures passed by value on 32-bit architectures
>   causing horrible codegen even with inlining. I think it's
>   usually fine up to a single register size.

...32-bit kernels are not ones where you would anticipate incredible
performance for one, for another if any significant issues arise we can
look at arch-specific workarounds.

I already have vma_flags_*_word*() helpers to do things 'the old way' in
the worst case. More can be added if and when anything arises.

Again, I don't think we should hold up the rest of the kernel (being able
to transition to not being arbitrarily limited by VMA count is very
important) on this basis.

Also I've checked 32-bit code generation which _seemed_ fine at a
glance. Of course again I've not good super deep on that.

>
> - clang's inlining algorithm works the other way round from gcc's:
>   inlining into the root caller first and sometimes leaving tiny
>   leaf function out of line unless you add __always_inline.

I already __always_inline all pertinent funcitons so hopefully that should
be no issue.

And for instance the assembly I shared earlier was built using clang, as I
now use clang for _all_ my builds locally.

>
>       Arnd

Thanks, Lorenzo

Powered by blists - more mailing lists