Hi,
On Sun, Jul 14, 2019 at 06:08:20PM +1000, Finn Thain wrote:
On Sun, 14 Jul 2019, Mike Rapoport wrote:
Even with those fixes I'm still concerned about the
SECTION_SIZE_BITS and MAX_PHYSMEM_BITS definitions.
Without implementing vmemmap support we are limited in their maximal
difference by 8 bits. That means that either minimal section size
would be 16M or the maximal physical memory size would be limited to
1G. I'm not that familiar with m68k machine variants to say if
either of these assumptions can be used.
While an Amiga could, in theory, have ca. 3.8 GiB of RAM, in practice
it's limited to 1 GiB, but most machines have only a fraction of that.
AFAIK, other m68k machines are similar. So a limit of 1 GiB sounds
fine to me.
But what's the impact of the minimal section size? What does it really
mean?
As my A4000 has 12 MiB of RAM at 0x7400000, and that seems to work, it
does not mean that address and size must be a multiple of 16 MiB?
Memory configuration varies wildly among machines.
IIRC, some Macs can have several discontiguous 1 MiB blocks.
Each section has a contiguous memory map for [section_start, section_end).
The section_start is SECTION_SIZE * section_nr.
The section_end is either SECTION_SIZE * (section_nr + 1) if the entire
section is populated or the end address of the memory chunk belonging to
that section.
For instance, with SECTION_SIZE of 16MiB your A4000 would have
section_start at 0x7400000 and section_end at 0x8000000.
If we were using, say, 8MiB sections, it would have two sections populated:
[0x7400000, 0x7c00000), [0x7c00000, 0x8000000].
The issue with having section size too big is that for machines that have
small chunks of discontiguous memory separated by less than SECTION_SIZE,
these chunks will map to the same section and this will cause creation of
unused memmap for the hole between those chunks.
E.g. with two chunks of 1MiB located at 0 and 14MiB, we'll have a single
section spanning 15MiB with wasted memory map covering the hole between 1M
and 14MiB.
On the other hand, presuming we want MAX_PHYSMEM_BITS set to 32, making the
SECTION_SIZE smaller won't work because we are running out of space in the
page flags :(
What about a Kconfig choice between say, two alternatives, an embedded (or
vintage) system and an emulated (or modified) system?
IIUC, a 1 MB section size would constrain physical memory to 256 MB which
seems reasonable for the former kind of system, while the latter would
have a 16 MB section size.
Perhaps additional Kconfig options, such as a 4 MB section size, could be
added later as and when the need arises?
We can add a Kconfig knob, but I'd prefer to avoid it and to have memory
model selection as simple and automated as possible.
I'll try to see what are the trade-offs of adding vmemmap or implementing
ARCH_HAS_HOLES_MEMORYMODEL to free holes in the flat memory map.
--
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Sincerely yours,
Mike.
