On Tue, Jun 24, 2025 at 5:30 PM Christoph Berg <m...@debian.org> wrote: > > Re: Tomas Vondra > > If it's a reliable fix, then I guess we can do it like this. But won't > > that be a performance penalty on everyone? Or does the system split the > > array into 16-element chunks anyway, so this makes no difference? > > There's still the overhead of the syscall itself. But no idea how > costly it is to have this 16-step loop in user or kernel space. > > We could claim that on 32-bit systems, shared_buffers would be smaller > anyway, so there the overhead isn't that big. And the step size should > be larger (if at all) on 64-bit. > > > Anyway, maybe we should start by reporting this to the kernel people. Do > > you want me to do that, or shall one of you take care of that? I suppose > > that'd be better, as you already wrote a fix / know the code better. > > Submitted: https://marc.info/?l=linux-mm&m=175077821909222&w=2 >
Hi all, I'm quite late to the party (just noticed the thread), but here's some addition context: it technically didn't make any sense to me to have NUMA on 32-bit due too small amount of addressable memory (after all, NUMA is about big iron, probably not even VMs), so in the first versions of the patchset I've excluded 32-bit (and back then for some reason I couldn't even find libnuma i386, but Andres pointed to me that it exists, so we re-added it probably just to stay consistent). The thread has kind of snowballed since then, but I still believe that NUMA on 32-bit does not make a lot of sense. Even assuming future shm interleaving one day in future version, allocation of small s_b sizes will usually fit a single NUMA node. -J.
