We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by posting ideas and requests to this portal to enhance a Power product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas and add comments to ideas that matter most to you
Get feedback from the IBM team to refine your idea
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The Power teams will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
IBM Unified Ideas Portal - https://ideas.ibm.com/ - Use this site to create or search for existing Ideas across all IBM products that are outside of Power, and track all of your personal interactions with all Ideas.
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?