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.
