From owner-freebsd-hackers Sat Aug 4 21: 9: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id D13E037B401 for ; Sat, 4 Aug 2001 21:09:03 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f7548TF95404; Sun, 5 Aug 2001 00:08:29 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3B6B8EAC.B4EBD5E8@mindspring.com> References: <3B6B8EAC.B4EBD5E8@mindspring.com> Date: Sun, 5 Aug 2001 00:08:26 -0400 To: tlambert2@mindspring.com, Rik van Riel From: Garance A Drosihn Subject: Re: How to visit physical memory above 4G? Cc: Julian Elischer , craig , freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:57 PM -0700 8/3/01, Terry Lambert wrote: >Rik van Riel wrote: >> > This is a trivial implementation. I'm not very impressed. >> >> > Personally, I'm not interested in a huge user space, >> >> Maybe not you, but I bet the database and scientific >> computing people will be interested in having 64 GB >> memory support in this simple way. > >You mean 4G, of course, since the process address space >remains limites to 32 bits... For what it's worth, we ran into some similar problem with a mainframe operating system I used to work on. We ended up creating something we called "named address spaces" for some user processes. Basically, it was just a quick swapping mechanism. In the context of IA-32, you could maybe have the first gigabyte of space as "fixed", and the remaining three gigabytes as multiple ("named") address spaces. Each named-address space could be between 1 and 3 gig, and you could have several of them. You'd make a system call to switch from one named-address space to a different one. It would not be practical for all user processes, but it would be useful for some of them. One ironic thing about this named-address space idea was that we had talked about it off-and-on for a few years, but we didn't actually *do* it until just as we were getting to the point where we could switch from 24-bit addressing to 31-bit addressing on our OS. We hit something where we just had to have the extra space "right away" (quicker than we could implement 31-bit addressing in userland processes). Once we decided to do this named-address space idea, it turned out it wasn't all that hard to implement. However, the current situation isn't quite the same as that one, and in the land of freebsd I'd think it would be better to concentrate on good support for the chips which do support 64-bit addresssing. I just thought it was worth pointing out that a process might well be limited to 32-bit addressing, and yet not be limited to 4-gig of usable memory space. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message