Re: PR 9725 and the m68k pmap

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

On Tue, 12 May 2009, Izumi Tsutsui wrote:

> > > (I don't know why these two traditional ports use different PAGE_SIZE)
>
> (Note is@ said because we could do it to reduce TLB shortage)

  I don't know exactly why the amiga used 8K pages (that was done before I 
got involved), but it would also be a potential performance improvement:
fewer page faults for a given memory range, and faster paging in from 
disk.

> As you can see pmap_bootstrap.c, L1 table and L2 table are allocated
> in one 4KB page which is allocated as the STE page for 68851/68030 MMU.

  Actually, the kernel mapping can use more than one page, since the 
additional pages for the L2 table will be allocated from contiguous 
physical memory.

  The problem comes from not being able to allocate contiguous physical 
pages for user MMU tables, and can only use one page for the L1 and L2 
tables.

  A quick and dirty workaround is to reduce the user address space by 
lowering the USERSTACK in vmparam.h (I can't remember for sure what value 
it would need to be, but it might be 0x0e000000 or 0x0c000000).

> To solve this, I guess we have to add some code to allocate
> a new page for additional L2 tables after all first L2 tables
> in the first 4KB page have been occupie in
> m68k/pmap_motorola.c:pmap_enter_ptpage().
> (around "panic("enter: out of address space")" line)
> I guess this is what Michael was working on.
>
> Michael also said that his change required modifications
> to all the m68k port's initial kernel MMU table setup.
> I don't know what exact changes are needed, but I guess
> L2 map allocation for Sysptmap (and also other special L2 mappings)
> needs to be changed, to map those L2 tables at right after
> other L2 tables (as amiga and atari do), not at the end of
> the 4KB STE page, to expand L2 entries in the L1 table.
> More other fixes might be required, of course.

  The primary problem is the requirement for contiguous physical pages for 
the L1/L2 tables, due to the current implementation.  If I remember 
correctly, the virtual address of the tables are accessed by subtracting 
the physical address of the L1 table from the physical address of the 
specific L2 table and adding that offset to the virtual address of the L1 
table.

  My approach was to allocate an additional table that is parallel to the 
L1 segment table, but contains the virtual address of the L1/L2 entries. 
That allows the L2 tables to be accessed using the virtual address 
directly, and doesn't require the underlying physical pages to be 
contiguous.  This requires each port to set up that additional table when 
it sets up the initial MMU tables.

  The current code I have been using still allocates the L2 table space in 
pages, and I have been wanting to try to use pools for the L1/L2 tables, 
but just haven't gotten ambitious enough to start yet.


--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA