Re: port-m68k/9725

[Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>]

The following reply was made to PR port-m68k/9725; it has been noted by GNATS.

From: Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: "Hauke Fath" <hauke%Espresso.Rhein-Neckar.DE@localhost>
Subject: Re: port-m68k/9725
Date: Thu, 14 May 2009 08:58:19 +0200

 Collecting further evidence... the thread at
 <http://mail-index.NetBSD.org/port-m68k/2001/07/oindex.html> has a concise
 analysis of the problem at
 
 <http://mail-index.NetBSD.org/port-m68k/2001/07/19/0002.html>
 "The problem in the PR is due to a limitation in the pmap code for
 68040/68060 cpus. I believe all the m68k ports have this limitation
 whereby a maximum of 7 level 2 segment tables can be allocated on behalf
 of a process. The problem described in the PR does not affect systems with
 68020/68030 cpus.
 
 A well behaved process will not notice any problem as long as it doesn't
 try to allocate more than 224MB of contiguous virtual address space (each
 level 2 segment table can map 32MB of address space). In practice, the
 per-process hard limits on VM will kick in before this on most/all m68k
 ports.
 
 The problem arises when a process uses mmap(2) to allocate virtual address
 space sparsely. It need only allocate one page at a time, but if each page
 is > 32MB away from the last the kernel will need to use a new level 2
 segment table to map it. Do this 5 times and all 7 will be used up. (Note
 that 1 is used for the process' text/data/bss and another for the initial
 stack)." (Steve Woodford)
 
 
 and a possible resolution at
 
 <http://mail-index.NetBSD.org/port-m68k/2001/07/21/0000.html>
 "On Fri, 20 Jul 2001, Jeremy Cooper wrote:
 > At this point I will stand up on a tiny sopbox and humbly offer that you
 > examine the sun3x pmap.  It is based on a design that Gordon Ross
 > suggested, and I implemented, for the 68030.  It might overcome some of
 > these limitations.
 
 Oh, nice one. :)
 
 I had no idea that was in the source tree. It's exactly what's needed to
 solve the 040/060 problem. It actually does so in a similar way to how I'd
 envisioned doing it... ;-)" (Steve Woodford).
 
 
 --
 "It's never straight up and down"     (DEVO)