The sizes of the two pools are not fixed; they depend on the memory utilization and the access pattern to the memory pages. In figure 6.6, only one moment in time is recorded, in the next moment the situation can look slightly different. The access of processes to compressed memory pages is not possible and also makes no sense, since the data is no longer available in the way the process saved it. If a process accesses data that has been compressed in the compressed pool, the operating system must first decompress it and store it in the uncompressed pool. Compressed memory pages cannot be paged out to a paging space.
AME can be activated or deactivated individually for each LPAR, but not dynamically. If AME is to be used for an LPAR, the so-called AME factor must be specified. This indicates the factor by which the actual memory should be expanded. The compression rate required for this is higher because the uncompressed pool remains uncompressed. In the picture above the compression rate was e.g. 1.75 and the achieved AME factor 1.5. A part of the memory must always remain uncompressed, otherwise the operating system can no longer work.
How well AME actually works in practice, depends very much on several factors:
- How well can the data be compressed, i.e. what compression rate can actually be achieved?
- After what time will data be accessed that has been compressed?
- Does the working set of memory pages fit into the uncompressed pool that results after less frequently used data has been compressed?
You must be logged in to post a comment.