Some responses point by point, inline:
On Tue, 10 Feb 2009 16:15:35 +0100, Kris Buelens <[email protected]>
wrote:
>As for the selection of "good old data" to be thrown out by CP:
>- Linux can tell CP that it no longer needs certain storage pages
>using a diagnose code. If it does ???
This would be Diagnose 10, the "release" function, as used by CMM (aka
CMM1), and other so-called "balooning" mods/drivers. If Linux releases a
range of pages using Diagnose 10, the paging space backing slots are free
.
>- CRM 2 is a Linux/CP co-operative feature by which CP would know what
>kind of data resides in which Linux pages. For example: if CP knows a
>page is used to cache disk data, it doesn't need to page it out, Linux
>can read it back in from its disks.
This would be CMMA, aka CMM2. When Linux puts a page in any non-stable
state, CP has the "opportunity" to see that state and revert the page to
the
"logically zeros" state, which would trigger an asynchronous discard of a
ny
paging slot holding the old contents. Of course, CP would have to happen
to
"look" at the page in just the right window to make that transition (and
depending on which non-stable state Linux is using, CP might have to hono
r
the Linux change ("dirty") bit and preserve the contents and revert the p
age
to stable state).
>- Apart from that, CP's selection of candidates to page out from
>central storage is not as clever is in z/OS: it only uses the last
>reference bit. That is why a z/VM installation would be configured
>with some amount of expanded storage, because there is a timestamp for
>each expanded storage page that allows CP to select old pages for
>pageout.
>
>--
>Kris Buelens,
>IBM Belgium, VM customer support
Not exactly true - CP's page selection criteria does not rely simply on t
he
most recent reference state. Our reference pattern management scheme is
actually quite a bit more sophisticated than the ones previously and
currently used by z/OS in that we maintain a user local approximate LRU
ordering of user pages based on user reference patterns over time, via th
e
User Frame Owned list of FRMTEs chained out of the VMDBK, and the Reorder
process. It's the ordering of the page frames represented on this list,
as
much as it is the most recent reference state (all compared to other fact
ors
such as demand, working set, RESERVED settings, locked pages, etc.), that
drive page selection criteria (and actually, in recent releases, we have
reference bit management that is actually several generations of referenc
e
bit history "deep" - for example, "referenced now AND referenced previous
ly"
have priority over either "referenced now but not referenced previously"
and
"not referenced now but referenced previously" pages).
More than anyone ever wanted to know, I'm sure. ;-)
- Bill Holder, z/VM Development, IBM Endicott
