On Mon, Apr 28, 2025 at 12:37 PM Lorenzo Stoakes <lorenzo.stoa...@oracle.com> wrote: > > On Mon, Apr 28, 2025 at 07:23:18PM +0200, David Hildenbrand wrote: > > On 28.04.25 18:24, Peter Xu wrote: > > > On Mon, Apr 28, 2025 at 06:16:21PM +0200, David Hildenbrand wrote: > > > > > Probably due to what config you have. E.g., when I'm looking mine > > > > > it's > > > > > much bigger and already consuming 256B, but it's because I enabled > > > > > more > > > > > things (userfaultfd, lockdep, etc.). > > > > > > > > Note that I enabled everything that you would expect on a production > > > > system > > > > (incld. userfaultfd, mempolicy, per-vma locks), so I didn't enable > > > > lockep. > > > > > > I still doubt whether you at least enabled userfaultfd, e.g., your > > > previous > > > paste has: > > > > > > struct vm_userfaultfd_ctx vm_userfaultfd_ctx; /* 176 0 */ > > > > > > Not something that matters.. but just in case you didn't use the expected > > > config file you wanted to use.. > > > > You're absolutely right. I only briefly rechecked for this purpose here on > > my notebook, and only looked for the existence of members, not expecting > > that we have confusing stuff like vm_userfaultfd_ctx. > > > > I checked again and the size stays at 192 with allyesconfig and then > > disabling debug options. > > I think a reasonable case is everything on, except CONFIG_DEBUG_LOCK_ALLOC > and I > don't care about nommu.
I think it's safe to assume that production systems would disable lockdep due to the performance overhead. At least that's what we do on Android - enable it on development branches but disable in production. > > So: > > CONFIG_PER_VMA_LOCK > CONFIG_SWAP > CONFIG_MMU (exclude the nommu vm_region field) > CONFIG_NUMA > CONFIG_NUMA_BALANCING > CONFIG_PER_VMA_LOCK > CONFIG_ANON_VMA_NAME > __HAVE_PFNMAP_TRACKING > > So to be clear - allyesconfig w/o debug gives us this yes? And we don't add a > cache line? In which case all good :) > > > > > > -- > > Cheers, > > > > David / dhildenb > > >
