Subject: Re: Things to work on
To: None <Richard.Earnshaw@arm.com>
From: David Brownlee <firstname.lastname@example.org>
Date: 05/24/2001 12:50:04
On Thu, 24 May 2001, Richard Earnshaw wrote:
> > On Thu, 24 May 2001, Richard Earnshaw wrote:
> > > > Make it SMP safe (hard to test, but we should be in case someone ever does an
> > > > SMP based arm box)
> > >
> > > Somewhat pointless at this time, particularly if it will impact
> > > performance. Until the models for cache coherency on SMP ARM systems are
> > > defined it isn't really sensible to consider this (IMO).
> > >
> > We may be able to obtain a bunch of hydra boards, complete with
> > schematics and details of the changes to make them work with
> > StrongARM CPUs. On a 16Mhz memory bus a fully loaded hydra is..
> > uh, a decidedly mismatched beast, but for two or three CPUs it
> > should give a boost.
> Hmm, muses.... a hydra with 3 kinnetics... OK, so they wouldn't be very
You _should_ be able to get up to five CPUs in the box. Visions of
using the kinetic ram for R/O pages and switching any page that
becomes dirty and has a mapping on more than one CPU to the base
RAM... Bookkeeping nightmare and you would want a very strong
process to CPU affinity :)
> > Do we have anywhere a brief document that gives an overview
> > of what a NetBSD pmap should provide, how it should be structured
> > to best handle various cache and MMU models, and specific areas
> > to watch out for? (As opposed to the current method for various
> > ports which is 'look at the latest i386 or alpha pmap' :)
> In -current you can "man 9 pmap", other than that there is only "Design
> and implementation of the BSD 4.4 OS", but that's getting away from NetBSD
> these days since it doesn't cover UVM or all the other recent changes
> (it's still good background though).
<sound of a laser printer powering up in the background>
Also available via
though the formatting is having some problems.
David/absolute -- www.netbsd.org: No hype required --