New values for vpm_throughput_core_threshold (enabling a more dynamic setting of the threshold).

Please re-submit this request once the requested questions have been addressed.

We are reviewing this request and would like to know more about the request. Please see below.

There are two parts to this request:

Part 1
Enable an additional value (for example '0' or 'E') for the vpm_throughput_core_threshold parameter. This value will set the threshold to the number of entitled (curr_proc_units) cores.

Are you aware that there is a ???0" value for vpm_throughput_core_threshold?

# schedo -h vpm_throughput_core_threshold
Help for tunable vpm_throughput_core_threshold:
Purpose:
Determines the number of cores to unfold in raw throughput mode before
switching to scaled throughput mode.
Values:
Default: 1
Range: 0 - 1920
Type: Dynamic
Unit: cores
Tuning:
This parameter determines the number of cores that will be unfolded in raw
throughput mode before switching to the specified scaled throughput mode.
In raw throughput mode more cores are unfolded when only the primary thread
of each unfolded core is busy. In scaled throughput mode, more cores are
unfolded only when the desired level of SMT exploitation has been reached
on the unfolded cores. This parameter can be used to achieve faster un-
folding up to a desired number of cores before entering scaled throughput
mode.

>>> A special value of zero can be specified to affect raw throughput mode up
>>> to the number of cores required to meet the entitled capacity of the
>>> partition. This parameter is only applicable when vpm_throughput_mode is
>>> non-zero.

We believe this may satisfy your needs.

Can you please confirm or let us know if you have more questions on this part?


Part 2
Enable an additional value (for example '-1') for the vpm_throughput_core_threshold parameter. This value will set the threshold to the one less than the number of entitled cores.

This sounds like an auto N-1 mode for the threshold which automatically sets the value to the number of entitled cores -1 and ensures that as the LPAR grows/shrinks (across dynamic add/remove operations or reboots) that the current number of assigned cores is reflected in the real-time setting used by AIX virtual processor management decisions. This is similar to the special setting of ???0" described above which keeps the number of entitled cores unfolded at N for the partition. (N = # of currently assigned entitled cores for the LPAR).

We are interested to know why you think LPARs do better with N-1 unfolded cores before switching to higher throughput modes?