Re: Paging file

Vern -

I'm not sure, but I believe that on the AS/400 all objects are divided up
into 4K pages, and each page has a virtual address.  The page size used to
be 512, prior to to RISC (and on the S/38).  The expansion of the page size
is what caused objects to increase dramatically in size when going from V3R2
to V3R6.

I believe that permanent objects have virtual addresses that don't change.
Temporary objects that get created during a job (PAG, etc) and temporary
system objects have temporary virtual addresses, thus you see the % perm
addresses and % temp addresses used on the WRKSYSSTS display.

If you had as much "real" memory as you had auxiliary storage, all pages
would be loaded into memory when requested and stay there.  When the amount
of memory needed exceeds the amount of "real" memory available, the paging
algorithm used by the AS/400 (inherited from the S/38) determines how to
kick a page from "real" memory back to auxiliary storage based on which page
is "least-recently-used".

I would guess that instead of creating a swap space, it puts the page back
where it came from on disk when it needs to reuse the "real" memory page.
It also knows whether or not a page it needs is in "real" memory or not, and
if it is already in "real" memory it uses the copy already in memory.

The "least-recently-used" algorithm was explained to me by Dick Sands, an
IBM SE that worked on my account in Dallas back in 1983.  I don't profess to
know the internals of the system...Some of this is pure speculation.  I'm
sure that Leif and the IBM'ers that are lurking out there know the details
about all of this.

Also:  I found an interesting white paper on the IBM site about the
architecture of the AS/400, if you haven't read it.

http://www-1.ibm.com/servers/eserver/iseries/whpapr/arch_nstar_perf.html#int
roduction

Steve Landess
Austin, Texas
(512) 423-0935


----- Original Message -----
From: "Vern Hamberg" <vhamberg@centerfieldtechnology.com>
To: <midrange-l@midrange.com>
Sent: Thursday, October 31, 2002 3:36 PM
Subject: RE: Paging file


> Loyd
>
> I'm not sure, but here are a couple things to consider from what I've
seen:
>
> 1. An IBMer I worked with said that all main memory is a map of DASD, or
> maybe he said disk. I still can't quite get my mind around that statement.
> But it suggests that all memory, even the 16MB you allocated, has an image
> on disk (my terms are not official - I'm making them up as I go)
>
> 2. You can allocate more than you have in main memory, and it will start
> creating segments out on disk - I've seen it in PEX traces
>
> 3. 16MB will probably fit in memory, but it also is connected to some
> location on disk - not yet written officially until it has been changed
> (becomes 'dirty'), maybe - if #1 means this.
>
> I'm going to say that SLS does set aside the space, on disk, that the
> pointer is aimed at - probably
>
> Make any sense?
>
> Vern
>
> At 02:04 PM 10/31/2002 -0600, you wrote:
> >If I dynamically allocate 16MB of memory using %alloc in a batch job,
where
> >is that 16MB stored if the job is paged to disk? Does SLS allocate a
pointer
> >for the program's "one-time" use?
> >
> >Thanks,
> >Loyd
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>