Hi Geert,
On Fri, Jul 12, 2019 at 04:28:26PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Fri, Jul 5, 2019 at 9:25 PM Mike Rapoport <[email protected]> wrote:
> > On Mon, Jul 01, 2019 at 01:56:25PM +0200, Geert Uytterhoeven wrote:
> > > On Sun, Jun 30, 2019 at 10:58 AM Mike Rapoport <[email protected]> wrote:
> > > > On Sun, Jun 30, 2019 at 12:54:49PM +1200, Michael Schmitz wrote:
> > > > > Am 29.06.2019 um 23:30 schrieb Mike Rapoport:
> > > > > >On Thu, Jun 20, 2019 at 06:46:28PM +0200, Geert Uytterhoeven wrote:
> > > > > >>On Wed, Jun 19, 2019 at 4:18 PM Mike Rapoport <[email protected]>
> > > > > >>wrote:
> > > > > >>>On Wed, Jun 19, 2019 at 09:39:40AM +0200, Geert Uytterhoeven wrote:
> > > > > >>>>On Wed, Jun 19, 2019 at 9:06 AM Geert Uytterhoeven
> > > > > >>>><[email protected]> wrote:
> > > > > >>>>>On Tue, Jun 18, 2019 at 8:10 AM Mike Rapoport
> > > > > >>>>><[email protected]> wrote:
> > > > > >>
> > > > > >>Thanks, that hack did fix CONFIG_SINGLE_MEMORY_CHUNK=y.
> > > > > >>
> > > > > >>Back to sparsemem...
> > > > > >>
> > > > > >>With CONFIG_SINGLE_MEMORY_CHUNK=n, and CONFIG_SPARSEMEM=y,
> > > > > >>it also fails. Diff between working single memory chunk and failing
> > > > > >>sparsemem:
> > > > > >>
> > > > > >> -Memory: 7796K/12288K available (2555K kernel code, 259K rwdata,
> > > > > >>700K rodata, 136K init, 153K bss, 4492K reserved, 0K cma-reserved)
> > > > > >> +Memory: 7816K/131072K available (2556K kernel code, 261K rwdata,
> > > > > >>700K rodata, 136K init, 157K bss, 123256K reserved, 0K cma-reserved)
> > > > > >>
> > > > > >>Oops, looks like it thinks there's memory from
> > > > > >>0x00000000-0x08000000,
> > > > > >>instead of 0x07400000-0x08000000.
> > > > > >
> > > > > >Yeah, I've made a mistake in the zone/hole size calculations as it
> > > > > >seems.
> > > > > >
> > > > > >Can you try this:
> > > > > >
> > > > > >diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
> > > > > >index 87d09942be5c..bf438a0da173 100644
> > > > > >--- a/arch/m68k/mm/motorola.c
> > > > > >+++ b/arch/m68k/mm/motorola.c
> > > > > >@@ -229,10 +229,8 @@ static void m68k_free_area_init(unsigned long
> > > > > >max_addr)
> > > > > > memblock_set_bottom_up(true);
> > > > > >
> > > > > > zones_size[ZONE_DMA] = max_addr >> PAGE_SHIFT;
> > > > > >- if (m68k_num_memory > 1) {
> > > > > >- holes_size = max_addr - memblock_phys_mem_size();
> > > > > >- zholes_size[ZONE_DMA] = holes_size >> PAGE_SHIFT;
> > > > > >- }
> > > > > >+ holes_size = max_addr - memblock_phys_mem_size();
> > > > > >+ zholes_size[ZONE_DMA] = >> PAGE_SHIFT;
> > > > >
> > > > > gcc fails to parse that line. Lost a holes_size, perhaps?
> > > >
> > > > Oops, indeed.
> > >
> > > Thanks, we're getting progress. My system is booting again from hard
> > > drive
> > > with CONFIG_SINGLE_MEMORY_CHUNK=n.
> > > When booting from an initrd, it still crashes, see attached dmesg.
> >
> > The initrd memory is reserved after the memmap is allocated and the initrd
> > gets overwritten. Can you try this hack please:
>
> [...]
>
> Thanks, will try after my holidays.
>
> > > Hence still to fix:
> > > 1. Proper solution for CONFIG_SINGLE_MEMORY_CHUNK=y,
> > > 2. CONFIG_SINGLE_MEMORY_CHUNK=n and initrd.
> >
> > 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 :(
> 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
--
Sincerely yours,
Mike.
