Re: [PATCH v3 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM

[Mike Rapoport <rppt@kernel.org>]

On Tue, Aug 25, 2020 at 08:47:41AM +1200, Michael Schmitz wrote:
> Hi Mike,
> 
> On 23/08/20 8:06 PM, Mike Rapoport wrote:
> > > > > 20 kB more total memory with sparsemem. Less memory used when booting
> > > > > to FastRAM, more used when booting to ST-RAM (checked right after boot
> > > > > on an idle system). The latter probably isn't significant.
> > > > When booting to FastRAM we still discard ST-RAM and only use it as
> > > > device memory for the framebuffer. So the total memory map size will be
> > > > smaller.
> > > Makes sense, but I was still surprised that replacing discontigmem by
> > > sparsemem saves 20 kB regardless of whether or not ST-RAM is used.
> > The problem with sparse, however, is the memory wasted for empty memmap.
> > For example, if the section size is 16M and there is, say, 17M of
> > FastRAM, the memory map will be created for 32M. This means that there
> > will be 3840 unused 'struct page' objects. :(
> 
> No such thing as a free lunch - that would be a case for the 1G VM limit
> (which I admit, I did not test!)?

For 1G physical memory limit the section size is 4M, so for a system
with 1M of RAM there will be 768 unused 'struct page' objects.
There is an option to free unused memmap, like ARM does [1], or even make
sparsemem to avoid allocating it from the beginning.
This should work, at least for the -mm case, because m68k has
pfn_valid() that does not depend on the memory model.

> In my case, ST-RAM is 14 MB, so only half of the last 4 MB wasted. Note that
> the top of the 16 MB physical area is mapped by early kernel startup as
> noncacheable (hardware registers). I hope this mapping is left alone by
> sparsemem.

Sparsmem will allocate an empty struct page for it, but it should not be
used and even initialized. And I didn't change the page table creation
code, at least not intentionally :)

> Now what would be required to allow use of the ST-RAM chunk (or any other
> memory area mapped out of order) by the kernel memory allocators?

Oh, that's a different story. This will require changes to the way we
create the virtual mapping of the physical memory and to __pa()/__va()
functions.

[1] https://elixir.bootlin.com/linux/latest/source/arch/arm/mm/init.c#L305


-- 
Sincerely yours,
Mike.