Chapter 2. Tuning considerations 25
Expanded storage
How much expanded storage, if any, should you define? We cannot provide a general answer
for this question. Logic might indicate that storage is better used as central storage instead of
expanded storage, but there is long-established folklore that OS/390® works better if some
expanded storage exists. (This is often related to “paging” of TSO swap sets into expanded
storage, but many other elements enter the discussion.) Also, some DB2 advocates
recommend the use of expanded storage.
A simple z/OS system, such as the AD system, works quite well without any expanded
storage. Long-term directions for zArchitecture will have no expanded storage. Most of the
exercises and tests we do for this IBM Redbook series do not use expanded storage. z/OS
running in “64-bit mode” does not use expanded storage.
We have seen cases where OS/390 performance (under FLEX-ES) was substantially
improved by reducing expanded storage and increasing disk cache sizes. (This comment
applies only when you are using raw disk devices, as should be the case for production
systems.)
2.8 Maximum allocations
There are four large memory “users” in a typical FLEX-ES implementation:
򐂰 S/390 central storage.
򐂰 S/390 expanded storage (if used).
򐂰 FLEX-ES disk caches (which typically involve large amounts of memory if you use raw
device interfaces).
򐂰 Linux free memory. Some cushion is needed to avoid Linux paging. Also, if you use
simple Linux files for emulated volumes (and if you do not specify large FLEX-ES disk
caches) then this memory functions as an automatic disk cache (not visible to FLEX-ES)
that has a substantial impact on performance.
We cannot directly control the amount of Linux free memory and we ignore this element in the
following discussion.
The theoretical maximum sizes are:
򐂰 2 GB for S/390 central storage
򐂰 16 Terabytes for S/390 expanded storage
򐂰 Approximately 478 MB (8191 tracks) cache for each emulated DASD control unit
However, Linux considerations reduce these numbers. Unfortunately, there is no simple
formula for workable maximum sizes. Also, this is an area that is sensitive to the level of the
Linux kernel being used and may substantially change with future Linux kernels. The following
discussion involves virtual memory sizes and parameters. You must always remember the
most important tuning rule:
do not let Linux page during S/390 emulation! Your real memory
size must be large enough (or your virtual memory assignments small enough) to prevent
Linux paging.
FLEX-ES obtains a separate shared segment (of virtual memory) for each of the following:
central storage, expanded storage, and disk cache for each emulated DASD control unit. The
maximum size of a shared segment is affected by the following:
򐂰 The value of Linux variable
shmmax. This sets the size of the largest allowed shared
segment request. The largest effective value for 32-bit Linux is 2 GB and FLEX-ES
automatically sets this value. (Larger values can be set but are ineffective.)

Get S/390 PartnerWorld for Developers, ITSO/EFS Project EFS Systems on a Linux Base: Additional Topics now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.