The following is from a presentation made on 86.10.07 at the SEAS
meeting on Jersey. List of SEAS meetings:
http://www.daube.ch/share/seas01.html#places

It describes a series of test on production VM/370 release 6 system
comparing PAM/CDF, PAM/EDF, and 4k/EDF. Lots of past PAM references
http://www.garlic.com/~lynn/subtopic.html#pam

                    Comparison of PAM, CDF and EDF

            pam/cdf         pam/edf        4k/edf
runl     2.89/39l0/33.   3.28/4103/4l.   3 72/1978/95.
run2     2.90/3768/49.   3.32/4ll5/54.   3.65/1965/79.
run3     3.01/3749/47.   3.35/4l23/8l.   3.66/1932/77.
runq     2.94/4033/34.   3.46/3975/46.   3.66/1920/63.
run5     3.0l/3472/36.   3.62/3884/68.   3.75/1948/85.
run6     3.08/3776/70.   3.46/3784/60.   3.79/1986/84.
run7     3.l3/3740/57.   3.37/3979/46.   3.75/1977/84
run8     2.99/3868/87.   3.4l/3836/52..  3.77/1958/88.

system     CPU      I/O    elapsed
           avg.     avg.    avg.
4k/EDF    3.72     1958      81.
PAM/EDF   3.4l     3836      56.
PAM/CDF   3.02     3790      52.

           min,     min.    min
4k/EDF    3.66     1920      63.
PAM/EDF   3.28     3784      41.
PAM/CDF   2.89     3472      33.

4k/EDF is the EDF CMS filesystem introduced in VM/370 release 6 used
with 4k block option.

PAM/CDF is the original CMS filesystem modified to use 4K records
rather than 800 and page-map interface.

PAM/EDF is the EDF CMS filesystem modified to use the page-map interface.

CPU is total (combination of virtual and supervisor).

The test was run on standard production system with other activity.  A
run consisted of doing the same exact operations involving pam/cdf
filesystem, then pam/edf filesystem, then 4k/edf filesystem. This was
repeated eight times and the avg. values and the minimum values used.

There is not a direct comparison between 4k/edf i/o and pam i/o.  For
4k/edf, I/O is reported as the number of virtual i/o operations
(independent of number of records transferred). There is slight
variability in 4k/edf i/o based on state of the filesystem and the
number of contiguous records that might be involved for operation.
For pam i/o, reported is the number of 4k page transfers (which might
also include other paging operations for the virtual machine during
the period and doesn't directly indicate the number of physical i/o
operations).

Both PAM test performed better than 4k/edf because of 1) reduced CP
overhead for supporting the operation, 2) better CP logic for chaining
multiple 4k transfers in single I/O,

The minimum values are going to be closest to base operation excluding
interferance from other workload on the system. pam/cdf is nearly
twice as fast and approx. 1/4 less cpu for the workload compared to
the same workload running on 4k/edf filesystem.

When the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

eventually replaced its 360/67 with 370/155, there was a port of a lot
of local modifications from cp67 to vm370. another page from the same
SEAS presentation

Release 2.15 CSC/VM

* Relocatable (floating) Shared Segments
* Paging Access Method (PAM)
* CP/67 Feedback controls
* CP/67 Working Set controls
* CP/67 GLobal LRU Page Replacement
* CP/67 Fastpath
* Restructured Page Supervisor
* Page and Swaptable Migration
* Q3
* Scheduling based on resource objectives
* Resource objectives either fixed or fairshare

note that much of this, I subsequently released in the resource
manager ... blue letter reference in recent posting
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux

a small subset of the cms & cp relocatable (floating) shared segments
http://www.garlic.com/~lynn/subtopic.html#adcon

(w/o paged-map support) had been released as DCSS (prior to the
resource manager release).

a couple other posts in this thread:
http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Reply via email to