S/390 PartnerWorld for Developers, ITSO/EFS Project EFS Systems on a Linux Base: Additional Topics

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.)