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?
--
> > Thanks!
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > [email protected]
> >
> > 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
>
>
