From mint-bounce@lists.fishpool.fi Thu Apr 7 23:45:42 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] MMU usage in MiNT, fork/mmap From: "Evan K. Langlois" To: mint@fishpool.com In-Reply-To: <1112909427.4255a6735cd6c@imp4-q.free.fr> References: <1112841566.22639.7.camel@taro.coolrunningconcepts.com> <1112902227.31903.3.camel@taro.coolrunningconcepts.com> <1112907140.31903.16.camel@taro.coolrunningconcepts.com> <1112909427.4255a6735cd6c@imp4-q.free.fr> Content-Type: text/plain Organization: Cool Running Concepts Date: Thu, 07 Apr 2005 16:42:00 -0500 Message-Id: <1112910120.31903.27.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.9 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: On Thu, 2005-04-07 at 23:30 +0200, Xavier Joubert wrote: > Hi Evan, > > > Selon "Evan K. Langlois" : > > OK, I remember some older machines doing that - think my 3b2 works > that > > way. That's gotta be a real performance killer though having to > copy a > > process at fork and again at every task switch. Is anyone actively > > You don't have to copy any data. A mere switch between two MMU trees > is enough. Thats my point. Right now, MiNT does copies instead of sharing the text pages and doing a copy-on-write for the data pages and just mapping the memory with the MMU. It doesn't have to if it would use the MMU, but I remember talk about being compatible with the old 68000 and no MMU, and no one wanted to add in the "has-an-MMU" case when the "no-MMU" case already worked, no matter how inefficient. > > working on a real virtual address space for MiNT? I have a feeling > this > > will eventually be necessary. > > I wrote a full virtual memory engine for TOS some years ago. ASM > sources are > available on Patrice Mandin's site ( > http://membres.lycos.fr/pmandin/download/src/sysinc.zip ). I was > young. I > didn't know mmap() at this time. I would write many things differently > today. Hmm .. was this about 10 years ago maybe? I think I remember it, or something similar. Probably lots of ideas we can pull from looking at the Linux and FreeBSD ports to the 68K as well. > It's been a long time I would like to work on implementing this in > MiNT. But I > never found time to study current code. We need to implement a virtual > address > space first. To be clean, this should interact closely with disk cache > management. Agreed! > > How different are the MMUs between the different processors? Looks like > > I need to get that stupid cross-compiler working soon. > > 040 and 060 MMUs are a subset of 030 MMU. Don't use any 030 specific stuff. > > Each processor family (030, 040 and 060) has different way to configure its MMU > and to recover from access fault. We need a code path for each. > > MMU trees are compatible. Thats about what I figured. Some minor differences in the setup and other details, but the bulk would be compatible. I suppose we should also be thinking about Coldfire as well, as the 4e core has an MMU. Believe it's almost identical to the 060's, but I'd have to check. -- Evan