On Sat, Aug 29, 2026 at 02:42:52PM -0400, Tal Zussman wrote: > On 2026-08-29 14:00 +0300, Mike Rapoport wrote: > > On Thu, Aug 27, 2026 at 05:19:30PM +0200, David Hildenbrand (Arm) wrote: > > > On 8/27/26 13:18, Lorenzo Stoakes (ARM) wrote: > > > > On Thu, Aug 27, 2026 at 12:16:32PM +0100, Lorenzo Stoakes (ARM) wrote: > > > >> So actually you're increasing by a cacheline and increasing the VMA > > > >> size by > > > >> 64 bytes, i.e. 1/3, which is unacceptable obviously. > > > >> > > > >> Maybe there's something that can be done with: > > > >> > > > >> /* forced alignments: 1 */ > > > >> > > > >> Perhaps? But that looks potentially ugly. > > > >> > > > > > > > > I say elsewhere (or think I do) but to highlight - I think probably we > > > > could fix > > > > this by putting the flags in the low bits of vm_uffd_state.ctx? > > > > > > if that's possible that would be clearly preferable memory-wise. > > > > This gives only 4 bits and makes this completely not extendable. > > Wouldn't it be 6 bits? struct userfaultfd_ctx is allocated with > kmem_cache_create() and SLAB_HWCACHE_ALIGN, and most of the flags are > only available on 64 bit, so it should be 64-byte aligned in the > relevant cases. > > (Not that 6 is that much better than 4... but it's a little more wiggle > room.)
I did remember that SLAB_HWCACHE_ALIGN could be as small as 16 bytes, but I didn't verify it for architectures that support fancy uffd modes. > It could in theory also be bumped up to 7 by setting align in > kmem_cache_create(). userfaultfd_ctx already takes 192 bytes due to > existing alignment. Aligning it to 128 bytes would make it 256 bytes, > adding 64 bytes to each uffd rather than each VMA. But this sounds like > more pain for little gain :) Yeah, even with as plenty as 7 bits :) > > So I think I'll drop this for now and wait until VMA grows another cache > > line or until having per-VMA uffd state rather than a pointer to per-fd > > context is a must. > > > > > -- > > > Cheers, > > > > > > David > > > > -- > > Sincerely yours, > > Mike. > > > > > > -- Sincerely yours, Mike.
