On 8/5/25 11:13, Srikar Dronamraju wrote:
* Shrikanth Hegde <sshe...@linux.ibm.com> [2025-08-01 19:27:22]:
Could you please add a link to patch on power utils on how it is being consumed?
I am not sure I understood your query, it looks a bit ambiguous.
If your query is on how lparcfg data is being consumed.
All tools that are consuming lparcfg will continue to use the same way.
Since this is not changing the way lparcfg is being consumed, I think it is
redundant information that need not be carried in all the changes/commits to
lparcfg. Such an information would be required when lparcfg file was
created.
I was saying you could point to power utils patch that you have sent which says
how
one would consume this.
https://groups.google.com/g/powerpc-utils-devel/c/8b2Ixk8vk2w
If your query is on how resource group data is being consumed by users.
Does MODULE_VERS need to increased?
All tools that are consuming lparcfg will continue to use the same way.
If there was some conditional changes that need to be done by the tools,
then we should have updated the same.
Hence there is not need to update MODULE_VERS.
Since there are two new fields user scripts might need change is why i was
suggesting
we might need to increase MODULE_VERS
@@ -78,6 +78,8 @@ struct hvcall_ppp_data {
u8 capped;
u8 weight;
u8 unallocated_weight;
+ u8 resource_group_index;
+ u16 active_procs_in_resource_group;
u16 active_procs_in_pool;
u16 active_system_procs;
u16 phys_platform_procs;
@@ -86,7 +88,7 @@ struct hvcall_ppp_data {
};
/*
- * H_GET_PPP hcall returns info in 4 parms.
+ * H_GET_PPP hcall returns info in 5 parms.
* entitled_capacity,unallocated_capacity,
* aggregation, resource_capability).
*
@@ -94,11 +96,11 @@ struct hvcall_ppp_data {
* R5 = Unallocated Processor Capacity Percentage.
* R6 (AABBCCDDEEFFGGHH).
* XXXX - reserved (0)
- * XXXX - reserved (0)
+ * XXXX - Active Cores in Resource Group
* XXXX - Group Number
* XXXX - Pool Number.
* R7 (IIJJKKLLMMNNOOPP).
- * XX - reserved. (0)
+ * XX - Resource group Number
* XX - bit 0-6 reserved (0). bit 7 is Capped indicator.
* XX - variable processor Capacity Weight
* XX - Unallocated Variable Processor Capacity Weight.
@@ -120,9 +122,11 @@ static unsigned int h_get_ppp(struct hvcall_ppp_data
*ppp_data)
ppp_data->entitlement = retbuf[0];
ppp_data->unallocated_entitlement = retbuf[1];
+ ppp_data->active_procs_in_resource_group = (retbuf[2] >> 4 * 8) &
0xffff;
ppp_data->group_num = (retbuf[2] >> 2 * 8) & 0xffff;
ppp_data->pool_num = retbuf[2] & 0xffff;
+ ppp_data->resource_group_index = (retbuf[3] >> 7 * 8) & 0xff;
ppp_data->capped = (retbuf[3] >> 6 * 8) & 0x01;
ppp_data->weight = (retbuf[3] >> 5 * 8) & 0xff;
ppp_data->unallocated_weight = (retbuf[3] >> 4 * 8) & 0xff;
@@ -236,6 +240,13 @@ static void parse_ppp_data(struct seq_file *m)
seq_printf(m, "unallocated_capacity=%lld\n",
ppp_data.unallocated_entitlement);
+ if (ppp_data.active_procs_in_resource_group) {
ppp_data.active_procs_in_resource_group can ever be zero?
If the entry is absent in lparcfg, then lparstat will print it as 0 (which
happens to be
default RG, while default RG may have processors)
If active_procs_in_resource_group is 0, then we are not printing the
resource group information. If active_procs_in_resource_group is non-zero
and resource_group_index is wrong, we need to report a bug to the firmware
to update it. Kernel is very transparent with respect to this information.
It can neither verify the information received nor should we even be doing
this.
The comment was more on the necessity of if statement there.
+ if (ppp_data.active_procs_in_resource_group) {
If one runs lparstat in the LPAR, that means
ppp_data.active_procs_in_resource_group is non zero. and when
ppp_data.active_procs_in_resource_group is zero, i don't think one can run
lparstat in any of such LPAR.
btw, ppp_data.active_procs_in_resource_group can be fraction between 0,1 or is
it always an integer number?
