On Fri, May 10, 2024 at 11:03:14AM +0200, Oscar Salvador wrote: > I did some research on which arches use CONFIG_SPARSE_MEMMAP/VMEMMAP or > none(using flatmem?). > > SPARSE_MEMMAP SPARSE_VMEMMAP > arc > arm X > arm64 X X > csky > hexagon > loongarch X X > m68k > microblaze > mips X > nios2 > openrisc > parisc > powerpc X X > riscv X X > s390 X X > sh X > sparc X X > um > x86 X X > xtensa > > arm, mips, parisc and sh operate with SPARSE_MEMMAP but are lacking code for > SPARSE_VMEMMAP. > I think these archs should be the first thing to focus on, to see if we can > make them work on SPARSE_VMEMMAP. > If we can, and when all arches can run on SPARSE_VMEMMAP, we can think of killing > SPARSE_MEMMAP. I'm a little concerned about having this conversation without the affected architecture maintainers in the room. However, I can speak to PA-RISC. Early models have a dense memory layout and we need not be concerned with them. I'm not quite sure about the PA-7200 to PA-8500 ccio based machines, would need to do some research. For the PA-8500+ astro based machines, the 256MB that would be in the range 3.75GB to 4GB is relocated to 67.75-68GB to leave space for PCI mmio. So if you have a machine with 8GB of memory (fairly typical for a J6000 machine), you'd have three ranges of memory: 0-3.75GB 4-8GB 67.75-68GB and I'd like to see an analysis of how laying out memmap would differ for those machines. The PA-8800+ pluto chipset does something similar, except it supports more memory and more PCI mmio, so a 32GB rp3440 would have a memmap: 0-3GB 4-32GB 259-260GB I think this would actually work better as three zones rather than three sections. It might match quite well with the TAO proposal.
