On Fri, May 10, 2024 at 11:03:58PM +0100, Matthew Wilcox wrote: > I'm a little concerned about having this conversation without the > affected architecture maintainers in the room. However, I can speak to > PA-RISC. Yes, having the architecture maintainers would be great. > 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. Maybe Mike can prove me wrong, but I assume that memblock will report the above ranges as memory, and the 3.75GB to 4GB as somewhat reserved. Then, we only mark those sections falling within the ranges reported as having memory by memblock as present, and we only populate the memmap for present sections. So, those ranges from above will be represented by present sections and hence with the vmemmap populated, and anything that falls off will not. I am not sure if I got your concern right though. > 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. But those are not really sections, are they? But rather memory ranges. Checking the code from parisc, sections are at 128MB granularity. So you will have 0-3GB -> 0 .. 23 section (memmap populated) 4-32GB -> 31 .. 255 section (memmap populated) 259-260GB -> 2071 .. 2079 section (memmap populated) -- Oscar Salvador SUSE Labs
