[email protected] (John Gilmore) writes:
> That said, Timothy Sipples is clearly right in general: The use of
> significant system-software resources to identify and share
> bit-equivalent pages, even big ones, dynamically is not likely to pay
> for itself in a z/OS environment. The major optimizations are already
> in place. The z/OS ASM does not, for example, page out unaltered
> pages after doing so once initially; and it is able to make this
> distinction efficiently because there is hardware support for
> distinguishing altered/stored-into pages from unaltered ones.
page replacement started out being only writting changed pages ... but
"big pages" appeared in 80s used with 3380s in 80s as attempt to
compensate for lack of appropriate paging devices. idea was doing a full
track (10 page) transfer in one operation (leveraging the 3380 transfer
speed increase by factor of four ... from 3330 800kbytes/sec to
3mbytes/sec ... but didn't have corresponding increase in arm access
throughput).
pages for same address space were removed from memory in groups of ten
... and written as single transfer to disk. a fetch for any page in the
group resulted in full track read for all ten pages (amortizing single
arm access across ten page transfer). the write was always done to a new
location ... basically first available location closest to moving arm
algorithm. to make this effective, it had to ignore whether a page had
been changed or not ... and remove groups of ten associated pages in one
operation (whether changed or not) all to the same track. additional
overhead of writting unchanged pages and potentially fetching unncessary
pages (wouldn't be used) in groups of ten ... was deamed to be more than
offset by the savings of one arm access for ten page transfer (along
with strategies for optimizing arm movement).
additional motivation was there were some non-IBM "fixed-head"
simulation paging disks that other vendors were offerring using
electronic memory ... eliminating arm access & rotational delay. the
sales argument was that "big pages" only had to do one arm access &
rotational delay per ten page transfer (in theory, negating the benefits
of electronic simulated disks).
about the same time, there was 3880-11 and 3880-13 controller caches.
3880-11 was 8mbyte of 4k block cache targeted at paging operations and
3880-13 was 8mbyte of full track cache targeted at file operations.
the 3880-13 marketing was that the cache had 90% hit rate. however, the
scenario was sequential file read of 4k records, 10/track. The first
record read from track would be miss, but the next 9 records read would
all be hits. if the application was changed to do sequential full track
buffered reads, cache hit rate would drop to zero.
I got into dustup with the 3880-11 product group that unless they
changed the mainframe software, the 3880-11 provided almost no benefit.
the issue was most configuration had about the same or more paged
mainframe memory (32mbyte 3081) than 3880-11 cache. The effective result
was that it would be highly improbably that there would be a record in
the the 3880-11 cache that wasn't in mainframe memory ("duplicates").
As a result, a page fault for something that wasn't in mainframe memory
wouldn't also be in 3880-11 cache (since the 3880-11 were totally full
of stuff that was also in mainframe memory). It was possible to do CCW
that would eliminate "duplicates" (increasing probability that there was
record in 3880-11 that wasn't also in mainframe), but that required
changing mainframe software.
I had earlier gotten into dustup with the VS2 group (early, pre-announce
SVS) over their myopic decision that when selecting pages for
replacement, that non-changed pages were selected before changed pages
(since it reduced work, memory location was immediately available
because it didn't require write). It wasn't well into the MVS release
cycle ... that it dawned on them that they were selecting non-changed,
shared, high-use linkpack pages for replacement before selecting lower
use, application private data pages.
past posts on page replacement algorithms and strategies
http://www.garlic.com/~lynn/subtopic.html#wsclock
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
