|
midrange.com
I'm going to stick with Sue and "Hey, both of you are right, but for
different parts of the equation".
In general program code (logic) will be demand paged to the pool containing
the process/job that first requested the page. Other processes/jobs
accessing the same page will access that already loaded page independent of
the pool associated with the second process/job. So far so good.
Now lets say we have a multi-processor system with local memory to each
processor (or set of processors). There may be some configurations where
there may be a significant performance difference between local memory
accesses and non-local memory accesses. In this case, the system might
optimize to detect that even though a given page is available in the memory
associated with another processor to replicate this page to local memory in
order to optimize performance. To do this replication you would want to
make sure the various replications cannot be changed and checking to see if
the page is hardware storage protected with read-only would be a good way
to check this. Program code can be set as hardware storage protected
read-only.
Now this optimization is not something you need to worry about and
certainly nothing to be relied on. It can and will vary by model,
configuation, PTF level, etc. But in very specific cases, in order to
maximize throughput of your iSeries, we may have limited duplication of
read-only pages in memory.
Simon Coulter
<shc@xxxxxxxxxxxx
om.au> To
Sent by: Midrange Systems Technical
midrange-l-bounce Discussion
s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
cc
11/24/2004 06:55 Subject
AM Re: Why separate pools?
Please respond to
Midrange Systems
Technical
Discussion
On 24/11/2004, at 11:17 AM, Sue Baker wrote:
> Hey, both of you are right, but for different parts of the
> equation. Data can be accessed in any memory page regardless of
> the memory pool it is in. Program specific logic and buffers
> cannot be accessed across memory pool boundaries, IIRC.
>
> IE, if I've got 2 memory pools for my interactive work and user z
> loads up pgma in pool 1 and then user y loads up pgma in pool 2,
> there will be two copies of pgma in memory. If user z reads
> record 12345 and then user y also reads 12345, user y will read
> from memory and not perform another fetch from disk.
I realise you have a us.ibm.com address but I'd bet money** this is not
correct. Program code (logic) is no different from any other
object--other than it is always demand paged. It is paged in to the
pool containing the process that first requests the address containing
part of the object. Once in main storage it is available to any other
process that needs the same page-even if that process is in a different
pool.
Program variables, open data paths, UFCBs, program buffers, etc. (all
the stuff that used to be in the PAG) are local to the process and as a
result remain in the pool to which the process is assigned but the code
is shared.
If you have 2 memory pools for interactive work and user z runs pgma in
pool 1 the the pages of the program required so far by user z will be
paged into pool 1. If user y runs the same pgma then user y will share
the code paged in by user z, even though user y is in pool 2, as long
as the code is still in main storage (i.e., its pages have not been
stolen by something else). If user y takes a different path through
pgma from user z then new pages may be brought in for user y and will
load into pool 2. If user z subsequently follows the alternate path
through pgma then user z will share the pages in pool 2 as long as they
are still resident. Both users will have completely separate program
variables, ODPs, etc.
I suppose it is possible that the increase in main storage sizes has
resulted in a change to the storage directories such that each pool has
its own directory for program pages and thus could keep multiple copies
of a program around but that seems contrary to the point of single
level store.
**$100 AUD donated to midrange.com if I'm proved wrong. Bill Davidson
has moved on but maybe Dan Hicks or Paul Remtema is still around. Bruce
Vining probably knows too.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software AS/400 Technical Specialists
http://www.flybynight.com.au/
Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\
Fax: +61 3 9419 0175 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
