Thanks all. Kernel builds are already covered on master: 612fcb5c5a2 maps user anonymous memory with real pages when CONFIG_ARCH_VMA_MAPPING is set.
For flat and protected builds I propose, combining Xiang's and Jukka's points: move MM_PGSIZE out of MM_PGALLOC, keep 4096 as the default with MM_PGALLOC, and use a small default without it, so no build gets new padding by default. sysconf(_SC_PAGESIZE) then returns CONFIG_MM_PGSIZE in all builds (today it falls back to CONFIG_PTHREAD_STACK_MIN), and anonymous mmap() aligns to it. memalign() is used only when MM_PGSIZE is larger than the heap alignment, so builds that do not use mmap(), or use a small page size, keep the same code size. If that is OK, I will send a PR. Marco Casaroli On Sat, Oct 10, 2026 at 12:54 PM Xiang Xiao <[email protected]> wrote: > > MM_PGSIZE(default is 4096) is already a Kconfig, but is guarded > by MM_PGALLOC. > so, the simple fix is move MM_PGSIZE out of MM_PGALLOC. > > On Sat, Oct 10, 2026 at 5:48 PM <[email protected]> wrote: > > > I think that enforcing any alignment in flat or protected builds is a > > terrible idea. "page" has very little meaning when there is no MMU. Also in > > SHM there was mandatory cache line alignment added, from which I had to > > specifically opt-out. > > > > For flat and protected build we could have additional config flags, > > defining the alignment if anyone needs it. And default that to 1 (0) bytes. > > > > - Jukka > > > > [email protected] kirjoitti lauantai 10. lokakuuta 2026: > > > Hello, > > > > > > I think there was a misunderstanding - I was not talking about wasted > > > RAM at all. The point was that currently, memalign is not included in > > > the build at all, it is removed by linker as unused code (if the build > > > is configured to do so.) If the linker cannot remove it, the image size > > > increases by more than 1% of total program (flash) memory. > > > > > > But to reiterate - if the change described in your first option only > > > affects things when mmap is actually in use (which, as Xiang Xiao said, > > > is rare), then it should be fine from 8bit AVR standpoint. The linker > > > will remove mmap for most use cases anyway and, in turn, remove memalign > > > as well, resulting in no overall code size increase. > > > > > > (On a side note, to my knowledge there is no concept of pages in 8bit > > > AVR and there is no need in the hardware to make aligned allocations at > > > all so it is somewhat likely that mm_memalign could simply be replaced > > > by a macro that calls mm_malloc. But that is off-topic for this thread.) > > > > > > On 2026-10-10 01:54, Marco C. wrote: > > > > Hello, > > > > > > > > The page alignment in 8-bit AVR is **2 bytes**. > > > > > > > > I don't think it hurts that much. > > > > > > > > What do you think? > > > > > > > > Marco Casaroli > > > > > > > -- > > Lähetetty Sailfish-laitteestani
