CA Datacom CADRE

Understanding CA Datacom® Symmetrical Multiprocessing and the IBM z Integrated Information Processor (zIIP)

By Kevin.Shuma posted 10-27-2020 06:57 PM

  

By Kevin Shuma – October 27, 2020

In an earlier post, Introduction to CA Datacom® and the IBM z Integrated Information Processor (zIIP), we discussed the delivery of the IBM zIIP processor and its exploitation in the CA Datacom environment. In that post, we covered zIIP exploitation and its implementation through the use of the Symmetrical Multiprocessing (SMP) capabilities available in the CA Datacom Multi-User facility (MUF). In this post, we discuss in detail the use of SMP capabilities including the use of WLM SRB tasks to offload eligible database workload to zIIP processors.

In the mid-1990s, CMOS technologies changed the mainframe forever by introducing the ability to house many low-cost processors in a single mainframe. Initially, these processors had smaller individual processing capabilities (MIPs) than the bipolar technology they replaced. However, when combined together, the many CMOS processors could provide processing power that equaled and then later far exceeded the capabilities of the bipolar mainframes. 

CA Datacom Version 9.0 delivered new Symmetrical Multiprocessing (SMP) to exploit CMOS processors. Prior to SMP, the MUF address space utilized a single TCB to process the database request workload. A limited amount of additional TCBs were started to handle additional asynchronous processing such as dataset opens. 

With the introduction of SMP processing, the MUF address space could be requested to start multiple TCBs to process the database request workload. These TCBs allowed multiple database requests to process in parallel. Each TCB could be started and loaded with a database request.  When a processor was available, it would pick up the TCB and execute the request processing.  Since TCBs are not directly tied to a processor, the MUF could have more TCBs active than physical processors to allow for better processing throughput.

As we discussed in the earlier post, with the introduction of zIIP processors, CA Datacom needed to enhance its database request processing to include WLM enabled SRBs to enable a portion of the database request workload to be eligible to execute on zIIP processors.

CA Datacom continues to evolve its use of TCBs and WLM SRBs to improve database performance, throughput, and the eligibility to shift processing to zIIP processors. 

In each Release of CA Datacom, the number and type of tasks started in the MUF address space can vary according to the current understanding of the best way to achieve the best possible processing throughput for the MUF address space.  Various MUF startup options can also trigger additional tasks (TCBs or WLM SRBs) to build to assist in processing.

In the following sections, we see snapshots of the tasks running in a given MUF address space. These examples are of a specific MUF address space. It is important to note that a similar snapshot of your MUF might have a slightly different set of tasks.


The following information lists the current task types found in the CA Datacom Release 15.1 MUF address space.

TASK TYPE – MAIN DBMUFPR 

A MAIN task is created when the MUF address space is started. This MAIN task controls the activity in the MUF address space. The MAIN task starts other tasks as needed for system functions or as requested by the MUF startup options. 

Depending on the implementation that is used, the MAIN task can also process user database requests. This topic is discussed further in later sections.

Note: The MAIN DBMUFPR task executes as a TCB and is not zIIP eligible.

TASK TYPE – SMP DBSMPPR

Depending on the MUF implementation enabled by the MUF start-up options, one or more SMP (Symmetrical Multiprocessing) tasks are created. These SMP tasks are created to assist in the processing of user database requests. 

Note: SMP DBSMPPR tasks execute as a TCB and are not zIIP eligible.


TASK TYPE – SMP *SRB-SMP

Depending on the MUF implementation enabled by the MUF start-up options, one or more *SRB (WLM Enabled SRB) SMP tasks are created.
These *SRB tasks are created to assist in the processing of user database requests. 

Note: SMP *SRB-SMP tasks execute as a WLM SRB and are zIIP eligible.


TASK TYPE – SUB DBSMAPR

These tasks are created as the TCB part of the SRB/TCB pair used for database request processing. For each of the SMP *SRB-SMP that is activated, a matching SUB DBSMAPR task is created.  

Note: SUB DBSMAPR tasks executes as a TCB and are not zIIP eligible.


TASK TYPE – SUB DBxxxPR (WHERE xxx IS A DATACOM PROGRAM NAME)

The MUF starts additional subtasks to handle system processing as needed. These subtasks perform critical system processing such as console management, dataset open/close, enqueues, and so on.

Note: SUB DBxxxPR tasks executes as a TCB and are not zIIP eligible.


TASK TYPE – OTHER SRB

Depending on the MUF implementation, a number of system functions can be used such as the use of XCF to route a database request from one LPAR to another. These systems functions can occur inside and outside the MUF. However, the CPU consumed by these system functions is charged to the MUF address space. 

Typically, this workload is not seen on the MUF address space task display. However, the workload is seen by external monitors that measure the total MUF address space CPU consumption.

Note: Other SRB work executes as a non-WLM enabled SRBs and are not zIIP eligible.


Selecting the processing mode for the MUF address space is done by setting a set of start-up options in the job that is used to start the MUF address space.  In this section, we discuss the three basic implementations of the MUF address space for database request processing.


Snapshot 1.  MAIN task (limited Symmetrical Multiprocessing) environment
The MUF executes with a single main task (TCB) that performs the majority of user request processing.  Depending on the Release of Datacom, one or more additional SMP DBSMPPR tasks (TCBs) can be created to assist the MAIN task is user request processing. In this mode, the MUF determines whether the SMP task is added. The user has no control over its specification or use.

There are a number of other SUB tasks (TCBs) that are allocated to handle system tasks such as open/close, memory management, and so on. 

Snapshot1 of tasks in a CA Datacom MUF executing with limited Symmetrical Multiprocessing enabled (SMPTASK start-up option is not specified)   

Generally, this type of processing is used for smaller workloads where no zIIP offload is needed.

Note: There is no zIIP eligibility in this MUF set-up.


Snapshot 2. MUF running in a Symmetrical Multiprocessing mode (TCB mode)
For larger workloads, the MUF address space can operate in a full Symmetrical Multiprocessing (SMP) mode. Consequently, the user tells the MUF how many additional SMP tasks should be available for database request processing. 

These SMP tasks operate in parallel and provide the ability to concurrently execute database requests. Generally, SMP processing is employed where there is a large enough workload to keep two or more tasks concurrently processing requests.  While sites can specify large numbers of SMP tasks, the typical site runs with 3-5 SMP tasks. 

The following MUF Startup option is used to start the MUF in SMP mode using TCBs.

SMPTASK x,y,z,TCB

where:
x – Indicates the maximum number of additional SMP tasks that can be allocated for database request processing
y – Indicates the initial number of additional SMP tasks that can be allocated for database request processing
z - Indicates the amount of workload “ready to run” that must be in the queue before the MUF activates the next additional SMP task.
TCB  - Indicates that all SMP tasks are started as TCBs and are not eligible for dispatching on a zIIP processor. Currently, TCB is the default value if it is not specified in the parameter.

In TCB mode, the MUF address space builds the additional specified tasks as SMP DBSMPPR (TCBs) to assist in request processing. The MAIN task and the additional SMP tasks work together to process database requests in parallel. 
As with main task processing, there are a number of other minor tasks (TCBs) that are allocated to handle system tasks such as open/close, memory management, and so on. 

Snapshot2 of tasks executing in a CA Datacom MUF with Symmetrical Multiprocessing enabled in TCB mode (SMPTASK 3,2,4,TCB)


Generally, this type of processing is used for larger workloads where no zIIP offload is needed.

Note: There is no zIIP eligibility in this environment.


Snapshot 3. MUF running in a Symmetrical Multiprocessing mode (SRB mode)
For larger workloads where zIIP offload is needed, the MUF address space can operate in a Symmetrical Multiprocessing (SMP) mode utilizing both WLM SRBs and TCBs for database request processing. Consequently, the MUF has multiple pairs of SRBs and TCBs available for database request processing. 

These database request processing tasks operate in parallel providing the ability to concurrently execute database requests. Typically, SMP processing is employed where there is a large enough workload to keep two or more tasks concurrently processing requests.  While sites can specify large numbers of SMP tasks, the typical site runs with 3-5 SMP tasks. 

The following MUF Startup option is used to start the MUF in SMP mode with SRBs and TCBs (zIIP enabled).

SMPTASK x,y,z,SRB

where:
x – Indicates the maximum number of additional SMP tasks that can be allocated for database request processing
y – Indicates the initial number of additional SMP tasks that can be allocated for database request processing
z - Indicates the amount of workload “ready to run” that must be in the queue before the MUF activates the next additional SMP task.
SRB  - Indicates that all SMP tasks are  started as SRB/TCB pairs.

Each pair has one
SMP *SRB-SMP that executes the zIIP eligible portion of the request and one SUB DBSMAPR that executes the non-zIIP eligible portion of the request. 

In this mode, the MAIN task is not used for user request processing and the SMP DBSMPPR (TCBs) are not activated. All user request workloads are directed to the SRB/TCB pairs.   

As with main task processing, a number of other minor tasks (TCBs) are allocated to handle system tasks such as open/close, memory management, and so on. 

Snapshot3 of tasks executing in a CA Datacom MUF with Symmetrical Multiprocessing with zIIP processing enabled (SMPTASK 3,2,4,SRB) 

This type of processing is typically used for larger workloads where zIIP offload is needed.

Note: In this environment,  zIIP eligibility is activated.


In Releases  15.0 and 15.1, sites specifying SMPTASK x,y,z,SRB to enable zIIP offload should also specify the following startup option for the MUF.

SMPTASK_USING_IEAV YES

This specification selects an improved dispatching mode for sites running SMPTASK x,y,z,SRB to offload processing to zIIP.  Many users have implemented this enhanced dispatching method which results in significant reductions in both GP CPU processing and zIIP CPU processing. 

This improved processing was introduced in Releases 15.0 and 15.1 as a selectable option. Due to its overwhelming success, plans are being made to make this the default option if it is not specified in the MUF.  We still recommend that you code the parameter as YES to get maximum effect and document the option selection in the MUF start-up options for visibility to the user.


The zIIP_USER_LIMIT is a seldom used MUF startup option (and not typically recommended).

The option allows a user to specify the limit (maximum) to the amount of eligible zIIP processing from a given SRB/TCB pair that is dispatched to a zIIP processor.   

For example, if a user were  running with SMPTASK 3,3,4,SRB they would have three SRB/TCB pairs for request processing. 

By specifying:

     ZIIP_USER_LIMIT 1,50

     ZIIP_USER_LIMIT 2,50

     ZIIP_USER_LIMIT 3,25 

The site is limiting the first two SRB/TCB pairs to a maximum of 50% of the zIIP eligible workload being dispatched to a zIIP processor. The third SRB/TCB pair is limited to a maximum of 25%.

As stated above, this parameter is not typically recommended. It is normally used only when sites are experimenting with zIIP processing to see various offload effects.


In summary, the ability to enable the MUF address space to offload database request workloads to the zIIP processors is a user selectable option.  The MUF address space must be running in Symmetrical Multiprocessing (SMP) mode with WLM SRBs enabled. The amount of eligible processing to offload varies from site to site based on software version and the settings within the MUF address space.  

The typical site that is activating the capability of the MUF address space to offload database request processing to the zIIP processor specifies:

SMPTASK x,y,z,SRB

SMPTASK_USING_IEAV YES

Indirectly, the site can increase zIIP offload eligibility by reducing physical I/Os. This is accomplished by:

  • Specifying larger SYSPOOL and DATAPOOL buffer pools 
  • Implementing MRDF covered processing for the index areas and data areas that experience high rates of Physical READ I/Os

With CA Datacom Release 15.1, customer sites have regularly seen zIIP offload percentages exceeding 80% of the MUF address space CPU which greatly reduces the GP (billable) CPU use.

Graphic comparing GP CPU and zIIP CPU seconds consumed in each of the three MUF environments described above when running the same workload.



If you would like further details on measuring CA Datacom’s exploitation of zIIP processing, watch for additional posts on:

  •       Measuring CA Datacom® Symmetrical Multiprocessing and the IBM z Integrated Information Processor (zIIP)
0 comments
22 views

Permalink