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
