Re: GCC 4.8 out of memory

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

phx@ wrote:

> On Tue, 2 Jun 2015 20:18:02 +0200
> Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> 
> > > Wasn't that 224MB for 040/060?
> > 
> > that was apparently fixed:
> > [...]
> 
> Oh, indeed. I forgot that this fix was related. So it's 480 MB for
> Amiga now, although m68k/pmap_motorola.c would allow 512 MB.

The "224MB" is a different limitation of 040/060 on hp300 derived pmap.
 http://nxr.netbsd.org/xref/src/sys/arch/hp300/hp300/pmap_bootstrap.c?r=1.58#157

Currently hp300 derived pmap puts both L1 table and L2 tables
(for 040/060 3-level MMU) into a single STE page, so we can have
only 7 (on 4KB/page) or 15 (on 8KB/page) L2 tables that can map
224MB ( 7 * 128 entries * 64 pages * 4096 bytes/page) or
480MB (15 * 128 entries * 32 pages * 8192 bytes/page) VA space.

I guess amiga's USRSTACK value was set intentionally to match
the 040/060 pmap limitation, to avoid panic in pmap_motorola.c.

Note mhitch's approach is to allow expanding the STE pages dynamically.
 http://mail-index.netbsd.org/port-m68k/2009/05/12/msg000142.html
 http://mail-index.netbsd.org/port-m68k/2009/05/12/msg000143.html

> > > > The bumped VM_KERNEL_PT_PAGES are necessary for up to 2GB RAM.
> > > [...]
> > It is the number of pages that is used for the initial MMU table
> > before the tables are expanded dynamically. After all, you need
> > some memory to allocate additional MMU pages from.
> 
> Ok. So you need these additional pages to be able to cover large
> address spaces, even if individual pages are not yet allocated/accessed
> in this area?

In the perfect world [tm], it would be better to probe
actual whole physical memory size and adjust "physmem" value
before pmap initialization, as x68k was changed recently.
 http://mail-index.netbsd.org/source-changes/2013/10/27/msg048734.html

---
Izumi Tsutsui