Avoid Remote VL CP Penalties By Utilizing Local Resources When Drawer Fit Fails

On IBM z16 servers, we have observed a significant increase in the cost of accessing data/memory located in a remote drawer. In certain scenarios, this can result in a notable increase in CPI, leading to an LPAR’s CPU utilization doubling -or even tripling- compared to its baseline without a proportional increase in workload.

To address this issue holistically, we are submitting a series of three related ideas. This is the third one of these three and address a specific condition observed in multi-drawer CECs, particularly when an LPAR is positioned in to the smallest (last) drawer in the CEC.

When the number of VL CPs required by an LPAR exceeds the capacity of the base drawer -either due to a customer miscalculation or a dynamic IRD weight adjustment. The LPAR may start to use VL CPs located in another drawer. This cross-drawer dispatching can result in sharp, short-duration CPU/MSU spikes (often under a minute thanks to IRD) These CPU burst are purely a side effect of the remote drawer penalty and not a reflection or increased CPU demand.

To mitigate this behavior, we propose the following enhancements:

1-     Local Core Utilization:

Instead of dispatching VL CPs from the remote drawers, PR/SM could assign unassigned/empty physical cores within the same drawer to fulfill the LPAR’s needs. Given that we have “absolute capping” feature, we believe there can be a mechanism implemented to keep the total CPU usage of that LPAR under the LCP’s assigned to it. So, the customer’s overall CPU usage would still remain within purchased limits.

2-     Overflow Redirection to VH zIIPs:
Alternatively, in this specific scenario, the temporary overflow workload could be dispatched to local VH zIIPs instead of VL CPs from the other drawers. This would provide performance continuity without incurring remote drawer latency.

Both approaches can ensure that IBM does not provide “free capacity” since the total capacity remains constrained by a capping mechanism similar to the “absolute capping”  No additional capacity would be granted, only reallocated more efficiently and this will help avoiding unnecessary performance degradation and MSU spikes that stem from physical drawer alignment mismatch.

This optimization would make IBM Z behavior more predictable in multi-drawer systems and improve fairness in capacity usage without impacting IBM’s licensing models.