Subject: Re: ARM port organisation (was: Re: NetBSD/hpcarm snap code)
To: Chris Gilbert <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 02/18/2001 00:08:17
> On Saturday 17 February 2001 9:31 pm, Jason R Thorpe wrote:
> > On Sat, Feb 17, 2001 at 07:20:23PM +0000, Ben Harris wrote:
> > > > Well, 32M is a pretty small address space -- it's going to affect
> > > > where you put the stack, is certainly going to affect shared
> > > > libraries, etc., and may constitute a new ABI.
> > >
> > > Heh. It's still bigger than the arm26 user address space.
> > >
> > > Hmm. Could you dynamically enable it for processes whose hard memory
> > > limits were low enough? That'd be cute.
> > I guess you could run-time switch, sure...
> Oddly enough the only thing I can think of that pushes the 32MB limit would
> be compiling, mozilla, and some of the window managers, eg kde2, and even
> then couldn't you just allocate the processes 2 sections apart until you hit
> 128 processes (gives you 128 processes of 64MB), then fill in the gaps if you
> can (ok won't work in all cases but would cover most desktop users, certainly
> wouldn't work for servers)
I don't think you can do that. All small procs must live in the 0-32Mb
virtual memory region (above that address and the cpu doesn't map in the
process-specific tag when doing VA translations, so the process needs its
own tlb tables.
> (of course I could be speaking rubbish, I've only glanced over the fcs stuff
> in the arm arm)
So could I... ;-)