Large and Giant Pages

IBM ®

International Technical Support Organization

© Copyright IBM Corp. 2005. All rights reserved.

CMG - 2013 CMG - 2013 Large and Giant PagesLarge and Giant Pages

Por que as pessoas de Mainframe não tem o Por que as pessoas de Mainframe não tem o direito de usar os aviões da FAB para seus direito de usar os aviões da FAB para seus

deslocamentos?deslocamentos?


Translation Look-aside Buffers (TLB) entries are lo cated internally in the PU (aside of the L1 cache) and ar e used by DAT to avoid going to CS for the translation tables data.

Before z/Architecture for every miss at TLB, DAT ne eds to go into two translation tables (segment table and page table) in central storage in order to translate a virtual add ress.

With z/Architecture (in the worst scenario) there i s a need of five tables (third region table, second region tabl e, first region table, segment table and page table). So it is very clear that now, every TLB miss is a performance disaster.

This performance problem is geting worse because: There is an explosion of pages above the bar used by WAS, DB2, z/OS itself . The number of TLB entries cannot grow in the same pace because TLB performance access delay (larger the worst).

The MVS deadly problemThe MVS deadly problem


Notes:Notes:

One would be inclined to think, that increasing the TLB size is a feasible option to deal with TLB-miss situations. However, this is not as straightforward as it seems. As the size of the TLB increases, so does the overhead involved in managing the TLB’s contents. Correct sizing of the TLB is subject to very complex statistical modelling in order to find the optimal trade-off between size and performance


The solution is to decrease the population of pages making some of them larger. With 4 K pages, holding all the add resses for 1 MB of storage takes 256 TLB lines. When using 1 MB pa ges, it takes only 1 TLB line. This means that large page size ex ploiters have a much smaller TLB footprint.Now, at z/Architecture we have three sizes of pages , that can be asked by programs through the IEARV64 macro :

4-K (traditional)1-M (large pages supported at z/OS 1.10 and up)2-G (giant pages supported at z/OS 1.12 and up)

Large pages are used by z/OS itself, JAVA (V6) a nd DB2 (V9).Pages with different sizes are already available in other plataforms, as such: AIX, Sun/Solaris...However, large and giant pages must be:

Above the bar (2-Giga) Fixed in Central Storage (never paged-out to page data sets)

The solution... The solution...


Notes:Notes:DAT is the piece of hardware contained in each PU i n charge of translating virtual address into real address. This task is accomplished through the access of CS tables manage d by z/OS. With 64-bit addressing it is possible to hav e up to 5 tables envolved in such translation (third region, second region, first region, segment and page tables). To improve DAT performance by avoiding these CS accesses, TLBs are introduced. After going through a translation using CS tables, DAT kepts the relation page/frame in a TLB entry. T LBs are located in fast internal memory within each PU. The n, before going through a CS table translation, DAT inspects TLBs looking for the needed page. In case of a hit the t ranslation process is much faster. z10 EC has 512 TLBs entries .However, due to the explosion of virtual addresses because the 64-bit capability, 512 is not enough to generate a good performance. Pages with 1-M addresses decreases the number of pa ges, thus improving DAT performance.


The amount of CS reserved for such pages must be spec ified at LFAREA keyword at IEASYSxx.

Required at program level by the keyword PAGEFRAMESIZ E at IARV64 macro. This option must be protected by RACF.

There are two types of TLBs: TLB1 and TLB2. Only TL B2s are candidates to contain 1-M pages information.

z196 têm 128 entradas na TLB1I [2 sets de 64 cada] e 51 2 entradas na TLB1D [2 sets de 256 cada] para Frames de 4K, mais 64 entradas [2 sets de 32 cada] para Frames de 1MB!

z/OS Real Storage Manager (RSM) keeps two available fram es queue. One for single frames and another for 256 contiguos frame s (to be assigned to 1-M pages). When the first queue is exausted, we may have migration from the second to the first, not the other way aro und.

So, when the large pages are requested it may take aw hile for the request to be satisfied.

Long-running work with high memory-access frequency is the best candidate to benefit from large pages.

More on 1-M pagesMore on 1-M pages


Segment tables and 1-M pagesSegment tables and 1-M pages

FC means Format Control

In Segment table there is a FC bit telling if the pointed page table has 4-K or 1-M pages.


n z/OS V1R12, the nucleus data area is planned to b e backed using 1M pages. This is intended to reduce the overhead of memory management for nucleus pages and to free translation lookaside buffer (TL B) entries so they can be used for other storage areas . This is expected to help reduce the number of address translations that need to be performed by the system and help improve overall system performance.

Nucleus and Large PagesNucleus and Large Pages


Flash Express memory is a silicon memory located at the PCIe I/O Drawer in the zEC12.

Initially is used as a page overflow area for centr al storage before page data sets. It is also used to k eep for the “fixed” large and giant pages when cental storage is under contention. It is accessed through the SSCH instruction.

Flash Memory and Paging Flash Memory and Paging


z/OS V1R13 IAR021I message

When the following message is issued, it means that the LFAREA parameter was specified but sufficient stora ge is not available:

IAR021I THE LFAREA WAS SPECIFIED BUT SUFFICIENT STORAGE IS NOT AVAILABLE

Large page new messageLarge page new message


With z/OS V1R13, a new command has been introduced that allows you to display what is the LFAREA current usage, as follows:

D VIRTSTOR,LFAREA

IAR019I 11.34.10 DISPLAY VIRTSTOR 846

SOURCE = 00

TOTAL LFAREA = 100M

LFAREA AVAILABLE = 100M

LFAREA ALLOCATED (1M) = 0M

LFAREA ALLOCATED (4K) = 0M

MAX LFAREA ALLOCATED (1M) = 12M

MAX LFAREA ALLOCATED (4K) = 0M

D VIRTSTOR,LFAREA new commandD VIRTSTOR,LFAREA new command


TOTAL LFAREA is the total size of the LFAREA in megabyte s. The amount displayed is the amount specified by installation (or defaulted to) using the LFAREA keyword in the IEASYSxx parmlib me mber.

LFAREA AVAILABLE is the amount, in megabytes, of avai lable 1 M pages.

LFAREA ALLOCATED (1 M) is the amount, in MBs, of alloc ated 1 M pages on behalf of 1 M page requests.

LFAREA ALLOCATED (4 K) is the amount, in MBs, of alloc ated 1 M pages on behalf of 4 K page requests.

MAX LFAREA ALLOCATED (1 M) is the high water mark, in MBs, of allocated 1 M pages on behalf of 1 M page requests.

MAX LFAREA ALLOCATED (4 K) is the high water mark, in MB, of allocated 1 M pages on behalf of 4 K page requests.

Message IAR019I meaningMessage IAR019I meaning


Giant pagesGiant pages

Giant pages have 2-G addresses.

Currently thre is not much inofrmation available ab out such.

However, I will make some predictions.

Some 2-G MVS address spaces will be totally maped i nto a giant page.

Slowly other address spaces will exploit such funct ion

It will be the dead of virtual storage with total c ompatibility

IBM ®



Transaction Execution FacilityTransaction Execution FacilityEm matadouros de cavalos, as pernas Em matadouros de cavalos, as pernas

são cortadas com eles vivos...são cortadas com eles vivos...


It provides ability to execute a group of instructi ons atomically (declaring the beginning TBEGIN and end of a trans action TEND), that is, either all their results are commit ted or none is, in true transactional way. May replace MVS locks.

Execution is optimistic: the instructions are execu ted but previous state values (storage and registers) are s aved in a “transactional memory”. If transaction succeeds, th e saved values are discarded, otherwise they are used to re store the original values (all or nothing). Or the DU complet es entirely or is reset to initial conditions. Se algum outro DU e stá tocando o conteudo, volta e desfaz tudo (only 1% of times).

TX is expected to provide significant performance b enefits and scalability to workloads by having the ability to a void most of the locks. This is especially important for heavily threaded applications, such as Java. WAS will be the first e xploiter.

Assunto de borla: Transaction Execution Facility (TX)Assunto de borla: Transaction Execution Facility (TX)


Transaction Execution FacilityTransaction Execution Facility

IBM ®



Acabou...Acabou...Vamos para as ruas. Mas sem pelegos Vamos para as ruas. Mas sem pelegos

e sem vândalos...e sem vândalos...

Large and Giant Pages

Technology

Transcript of Large and Giant Pages