Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!lll-winken!uunet!philmtl!philabs!linus!munck
From: munck@linus.UUCP (Robert Munck)
Newsgroups: comp.arch
Subject: Re: 386/486 Virtual Memory Question...
Message-ID: <56195@linus.UUCP>
Date: 15 Jun 89 11:47:13 GMT
References: <243@mipos3.intel.com> <4056@ima.ima.isc.com> <55957@linus.UUCP> <4067@ima.ima.isc.com>
Reply-To: munck@faron.UUCP (Robert Munck)
Organization: The MITRE Corporation, Bedford MA
Lines: 55

In article <4067@ima.ima.isc.com> johnl@ima.UUCP (John R. Levine) writes:
>In article <55957@linus.UUCP> you write:
>>...  I suppose that if you could only leave two
>>gigabytes between them, there wouldn't be enough room for them to grow.
>
>Of course you can do that, and indeed that's exactly what real systems do,
>but it's a hack forced on you by the poor implementation of the chip's
>addressing architecture.

The sarcasm of "only two gigabytes" seems to have been missed.  Given
that there has to be an upper limit, it seems to me that one three
orders of magnitude higher than the largest code/stack that 99.9% of
applications currently use is "big enough."  I'm sure there are
pathological applications that need more.

In fact, since the 386 implements "grow-down" segments intended for
things like stacks, the cleanest implementation will give code and stack
separate segments.

>>>In theory you could have a larger total address space and play
>>>games with mapping segments in and out. 
>>>
>>The "games" are no stranger than mapping virtual pages into and out of
>>real memory; in fact, the two are done exactly the same way..
>
>Actually, the games are considerably stranger than mapping virtual pages in
>and out, and there are real limitations. When you map pages, every page is the
>same size and is tiny compared to the size of the address space. When you map
>segments, they're all different sizes and each one is potentially as big as
>the full address space.

Sure, but you still have page mapping to help.  By changing the mapping,
you can move segments around in the linear address space very easily,
and therefore it's easy to make them "fit."

>Assume you have two sparse segments, each slightly
>bigger than 2GB, and you do a MOVS or something from one to the other. The
>system has to map in both segments at the same time, but it can't because the
>linear address space isn't big enough. This is a real problem.

It's a real problem only if you and a lot of other people are constantly
in need of segments on the order of a gigabyte, and the nature of your
applications is such that there's no way to use multiple smaller
segments.  As I said, there has to be a upper limit.  Criticism of Intel
is valid only if that upper limit is demonstratibly too small.

>As noted by another poster, the cost of mapping segments is also very
>high -- any time you change a page table you have to flush the entire TLB.

In my experience, not a problem.  The cost is a handfull of microseconds
to reload the TLB -- having to map through the directory and page tables
a couple of dozen times, maybe as much as ten microseconds.  This is
several orders of magnitude less than other costs of a virtual memory
such as page read time.
                        -- Bob Munck, MITRE Corporation