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 = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute or [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
