Hi Mike, thanks for addressing this longstanding issue! Am 08.05.2019 um 22:09 schrieb Mike Rapoport:
Hi, This is the first attempt to replace DISCONTIGMEM with SPARSEMEM on m68k for systems with !SINGLE_MEMORY_CHUNK set. With SPARSEMEM there is a single node for the entire physical memory and to cope with holes in the physical address space it is divided to sections of up to 16M. Each section has it's own memory map which size depends on actual populated memory.
I tested this using ARAnyM and it works both with kernel loaded to ST-RAM (low address chunk) and FastRAM/TT-RAM (high address chunk).
I do wonder though - is the DMA memory pool reserved in atari_stram_map_pages() (which was left unmapped previously if the kernel was loaded to FastRAM, due to constraints of the discontigmem memory model) considered already allocated now with sparsemem, and won't be used in 'normal'memory allocations? Haven't seen any evidence to the contrary, but I've not put the system under any kind of memory pressure.
With these caveats: Tested-By: Michael Schmitz <schmitzmic@xxxxxxxxx> Cheers, Michael
The section size of 16M was chosen pretty much arbitrarily as I couldn't find specs for systems with e.g. Zorro memory extensions. Mike Rapoport (3): m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM m68k/mm: switch from DISCONTIGMEM to SPARSEMEM arch/m68k/Kconfig.cpu | 12 +++++-- arch/m68k/include/asm/page.h | 2 ++ arch/m68k/include/asm/page_mm.h | 6 +++- arch/m68k/include/asm/sparsemem.h | 8 +++++ arch/m68k/include/asm/virtconvert.h | 2 +- arch/m68k/mm/init.c | 8 ++--- arch/m68k/mm/motorola.c | 64 ++++++++++++++++++++++++++++++------- 7 files changed, 83 insertions(+), 19 deletions(-) create mode 100644 arch/m68k/include/asm/sparsemem.h
