Cooperative Memory Management and Collaborative Memory Management Assist Results
The results obtained for ten guests for z/VM® 5.2 and z/VM 5.3 are compared with the results obtained on z/VM 5.3 with VMRM-CMM and CMMA enabled.
To achieve these results, we needed to upgrade the Linux® system to SLES10 SP1 and apply the fixes listed in Software setup to enable VMRM-CMM and CMMA requests to Linux to perform memory management. We did these runs only at the ten guest scenario to show the impact at the point with the highest memory pressure.
Throughput
Figure 1 shows the throughput for ten guests normalized on the throughput for z/VM 5.2.

Observations
VMRM-CMM has almost three times the throughput observed for z/VM 5.2 and CMMA has more than double the throughput of z/VM 5.2. With respect to z/VM 5.3, CMMA has 8% more throughput and VMRM-CMM has 50% more throughput. When compared with the five guests baseline on z/VM 5.3, the ten VMRM-CMM enabled guests achieve 87% of the baseline throughput, while the CMMA enabled guests achieve 63% of the baseline throughput. With both VMRM-CMM and CMMA enabled, the throughput decreased from the run with only VMRM-CMM enabled. It appears that for this workload, CMMA has a small negative impact on throughput when used in combination with VMRM-CMM. The VMRM-CMM and CMMA-enabled combination is not compared further.
CPU utilization
Figure 2 compares the CPU utilization results for ten guests using z/VM 5.2, z/VM 5.3, CMMA, VMRM-CMM, and VMRM-CMM and CMMA combined.

Observations
Enabling either CMMA or VMRM-CMM results in higher CPU utilization than z/VM 5.3 without either of them enabled. However, throughput is also much higher. Both VMRM-CMM and CMMA have lower z/VM overhead, with CMMA having the lowest overhead. The ten guests on VMRM-CMM reached 963% utilization, which means the system is nearly fully utilized. The combination of both VMRM-CMM and CMMA shows a guest CPU utilization similar to the CMMA only case. The overall CPU utilization for the LPAR is about the same as for the VMRM-CMM only case.
DASD paging space
Figure 3 compares the total number of gigabytes of DASD space that are used to hold guest pages on z/VM 5.3, z/VM 5.2, CMMA, VMRM-CMM, and VMRM-CMM and CMM combined.

Observations
VMRM-CMM and CMMA significantly reduces the number of pages moved to DASD paging space. VMRM-CMM uses less than 5 GB of DASD paging space. For the VMRM-CMM and CMMA combination, the paging space is still around 5 GB, but slightly higher than with VMRM-CMM alone.
Page movement
Figure 4 compares page movement between z/VM 5.2, z/VM 5.3, CMMA, VMRM-CMM, and VMRM-CMM and CMMA combined.

Observations
Compared to z/VM 5.3, CMMA shows more than a 50% decrease in the rate at which pages are moved and VMRM-CMM shows that page movement rate has decreased to less than 400 pages per second for main storage to XSTOR and less than 200 pages per second from XSTOR to DASD. For the VMRM-CMM and CMMA combination, the page movement rates are similar with a slight decrease, which corresponds with the observed decrease in throughput.
Conclusion
Using VMRM-CMM with z/VM 5.3 produced the best throughput and lowest z/VM paging activity at a planned memory overcommitment of 100%. As Table 1 shows, the real memory overcommitment for CMMA and VMRM-CMM is significantly lower.
The total system memory of 80 GB (20,971,520 pages) is overcommitted as follows:
| 10 Guests | Pages Not in Memory (= paged out) | Real Overcommit (pages used: memory) - 1 | Planned Overcommit (virtual : physical) - 1 | Throughput % From Baseline | |
| XSTOR | DASD | % | % | % | |
| z/VM 5.2 | 1045785 | 20754432 | 104 | 100 | baseline |
| z/VM 5.3 | 1039536 | 26647552 | 132 | 100 | 189 |
| CMMA | 1032254 | 13497344 | 69 | 100 | 204 |
| VMRM-CMM | 986883 | 1215888 | 11 | 100 | 283 |
| VMRM-CMM & CMMA | 484979 | 1480396 | 9 | 100 | 273 |
While CMMA reduced the paging activity of z/VM, it did not result in a significantly higher increase in throughput. Enabling VMRM-CMM produced significantly better throughput performance and an impressive reduction of the page space utilization. This very good result for VMRM-CMM is expected to be specific for this workload and can not be generalized without further tests for other workloads.