Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!tektronix!tekcrl!terryl
From: terryl@tekcrl.CRL.TEK.COM
Newsgroups: comp.os.misc
Subject: Re: a very naive Question???
Message-ID: <3154@tekcrl.CRL.TEK.COM>
Date: 12 Oct 88 17:13:31 GMT
References: <837@amethyst.ma.arizona.edu>
Reply-To: terryl@tekcrl.CRL.TEK.COM
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 61

In article <837@amethyst.ma.arizona.edu> chris@spock.ame.arizona.edu (Chris Ott) writes:
>
>mark@hubcap.UUCP (Mark Smotherman) writes:
>> > In article <835@amethyst.ma.arizona.edu>, chris@spock (Chris Ott) writes:
>> >      Close, but not quite. Demand paging involves only the code portion of
>>                                                    ^^^^^^^^^^^^^^^^^^^^^
>> > the program.
>>
>>
>> Page only the code portion?  News to me!
>
>     I didn't mean that only the code portion is paged, I meant that only
>the code portion is _demand paged_. Here, I made a slight mistake. It's
>not just the code portion, it's the _text_ portion. This includes code
>_and_ initialized (usually read-only) data. Sorry. Anyway, as in the Sun
>Commands Reference manual, under ld(1):
>
>     -z  Arrange for the process to be loaded on demand from the resulting
>         executable file rather than preloaded.
>
>i.e. Rather than loading the entire file into memory at once, like some
>systems do, load the pages as they are needed. This only applies to the
>text portion of the program, not data, like local variables of subroutines
>and such.


     Uh, not quite, Mr. Ott. You can demand page the DATA portion of a process.
Almost all of the various derivatives of 4.n BSD (n >= 0) I've looked at do
support demand paging for both the data and the stack portion. In fact, here's
a portion of the ld(1) man page on a VAX(slightly paraphrased):

     -z	Arrange for the process to be loaded on demand from the resulting
	executable file (413 format) rather than preloaded.
	This is the default.  Results in a 1024 byte header on the output
	file followed by a text and data segment each of which have size a
	multiple of 1024 bytes.....

     The reason for the "multiple of 1024 bytes..." is for demand paging;
it makes it easier. Now, it may be that the Sun only supports demand paging
for the text portion of a process (I have absolutely no idea, for I have no
experience with any of Sun's products...), but since they were so heavily
based on 4.2 BSD (now a mixture of 4.2 and Sys V), I doubt that they would
take out the demand paging of data. Once you've got it for text, it's not
that difficult to implement it for data and stack (after all, parts are
parts, blocks are blocks, memory is memory, etc... (-:).

     In order to make myself a little more clear, here's what a generic
4.2 system does for demand paging: The text and data are demand paged FROM
THE FILE where the program resides (but ONLY for the first page fault);
bss and stack pages are demand paged, also, but they are a paged differently
than text and data. bss and stack pages are marked as zero-fill-on-demand
(i.e. the first time a process references a bss or stack page, 4.2 will
map it into the process's address space, zeroing the contents of the page
first). Now, regardless of the type of page, when a page is paged out, it
is written to a swap device; when that page is referenced again, it will be
paged in from the same swap device. This is true for a generic 4.2 system,
though I've seen a couple of systems that NEVER write out text pages (since
they will never be modified), and demand page the text page from the file
where the program resides yet again.

     I hope this clears things up somewhat.....