Re: Paging file -- MIDRANGE-L

Steve - article looks interesting.

As far as disk organization goes, I think we're talking about 2 different
areas. Yes, the basic unit now is 4k pages. And that is the value returned
by the MATRMD (materialize Resource Management Data) instruction (callable
from C/C++/RPGLE/maybe even CLLE/CBBLE. This'll be the minimum transfer
request size (request made to Storage Management, I think, the thing that
does all the work related to DASD.

But, with expert cache, and *CALC for shared pools, this transfer request
size can go up, so that IO is more efficient. Truly sequential data
read/writes will go at 128k eventually. Non-data goes at a max of 32k. Now
these are made up of multiple contiguous 4k pages. And truly random data
access (reading a keyed logical by key that does not match the physical
order) will be choked down to 4k transfers (MATRMD has an option that lets
you retrieve this info).

Then there is the matter of balancing objects across multiple arms, and
this is where the 1meg extent stuff comes into play. The largest contiguous
portion of any object will be 1meg in size - made up, again, of those 4k
pages. The most efficient IO will be with 128k IO requests, so it takes 8
of these to get one extent in or out. And normally, a 6meg object will be
spread across 6 or more arms.

So the basic unit is 4k, yes, but IO requests will be as large as
practical, so as to reduce the number of physical IOs, which are the
bottleneck.

I asked my boss, a former IBMer, about the idea that CPU memory always has
some connection to DASD He said that's right. So total memory on a 400 is
really the total DASD - primary doesn't ADD to meory capacity, it only
functions as the playground in which the processor can play.

An interesting experiment is to allocate a large portion of memory (larger
than available primary memory - or more than the pool you are in has in
it). You will see, in a DSPJOB opt 3, that "Temporary storage used" will
have gone up. And if you free that allocated memory, that temp storage is
still allocated to you job. And if you allocate storage to the same
variable again, temp storage will go up AGAIN. And this is auxiliary
storage, or DASD.

BTW, I had the good fortune of working in the Data performance lab in 2001,
testing some of the new SQL stuff for V5R2. These are some of my
recollections, but I may not be completely accurate - but I'm close, I
think. But senior moments o'erwhelm betimes.

Regards

Vern

At 05:33 PM 10/31/02 -0600, you wrote:

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