Date: Fri, 6 Oct 2000 00:44:34 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Terry Lambert <tlambert@primenet.com> Cc: Wilko Bulte <wkb@freebie.demon.nl>, Matthew Jacob <mjacob@feral.com>, FreeBSD-alpha mailing list <freebsd-alpha@FreeBSD.ORG> Subject: Re: max memory on Alpha? Message-ID: <Pine.BSF.4.21.0010060041080.94692-100000@salmon.nlsystems.com> In-Reply-To: <200010052209.PAA16408@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Oct 2000, Terry Lambert wrote: > > > Do you know *if* there is a hard limit at 2Gb? > > > > I don't think there is a *hard* limit for the basic VM system but I > > imagine it might have problems finding a large enough contiguous region to > > map the vm_page_t structures. The main limitation is in the i/o system as > > previously noted. > > It seems to me that the contiguity requirement is bogus. > > If contiguity is other than an implementation artificat (i.e. > it is a true hardware requirement), then it seems to me that > it is time to provide a mechanism for defragging KVA space, > or place the vm_page_t structures in a seperate virtual > address space. The vm_page_t's are initialised *very* early and are generally mapped by a very simple subset of pmap. Currently, the VM system assumes that it can map a single contiguous physical extent for them although it could conceivably be slightly smarter. > > On a related note, I've always though that drivers (and their > related kernel threads, should such obnoxious things become > more commonplace) ought to run in their own VA space, on a > per driver basis, so that a bad driver couldn't pee in the > pool. This would keep bad drivers from actually crashing > the system, short of a halt or going into a tight loop (even > then, a timer interrupt should be able to recover the halt, > and a preemption should be able to recover the loop, if it > is a kernel thread -- or even generally, if kernel preemption > were to be supported). This would probably waste far too much performance to be actually useful. On the other hand, there are OSs which do this so perhaps the cost is manageable. Much too hard to implement within the existing kernel infrastructure though. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010060041080.94692-100000>