Date: Thu, 5 Oct 2000 22:09:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wkb@freebie.demon.nl (Wilko Bulte) Cc: dfr@nlsystems.com (Doug Rabson), mjacob@feral.com (Matthew Jacob), freebsd-alpha@FreeBSD.ORG (FreeBSD-alpha mailing list) Subject: Re: max memory on Alpha? Message-ID: <200010052209.PAA16408@usr05.primenet.com> In-Reply-To: <20001005232805.B7134@freebie.demon.nl> from "Wilko Bulte" at Oct 05, 2000 11:28:05 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. 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). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200010052209.PAA16408>