[PATCH] pseries/lparcfg: Add resource group monitoring

[PATCH] pseries/lparcfg: Add resource group monitoring

[Srikar Dronamraju]

Systems can now be partitioned into resource groups. By default all
systems will be part of default resource group. Once a resource group is
created, and resources allocated to the resource group, those resources
will be removed from the default resource group. If a LPAR moved to a
resource group, then it can only use resources in the resource group.

So maximum processors that can be allocated to a LPAR can be equal or
smaller than the resources in the resource group.

lparcfg can now exposes the resource group id to which this LPAR belongs
to. It also exposes the number of processors in the current resource
group. The default resource group id happens to be 0. These would be
documented in the upcoming PAPR update.

Example of an LPAR in a default resource group
root@ltcp11-lp3 $ grep resource_group /proc/powerpc/lparcfg
resource_group_number=0
resource_group_active_processors=50
root@ltcp11-lp3 $

Example of an LPAR in a non-default resource group
root@ltcp11-lp5 $ grep resource_group /proc/powerpc/lparcfg
resource_group_number=1
resource_group_active_processors=30
root@ltcp11-lp5 $

Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
---
 arch/powerpc/platforms/pseries/lparcfg.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
index cc22924f159f..6554537984fb 100644
--- a/arch/powerpc/platforms/pseries/lparcfg.c
+++ b/arch/powerpc/platforms/pseries/lparcfg.c
@@ -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)  {
+		seq_printf(m, "resource_group_number=%d\n",
+				ppp_data.resource_group_index);
+		seq_printf(m, "resource_group_active_processors=%d\n",
+				ppp_data.active_procs_in_resource_group);
+	}
+
 	/* The last bits of information returned from h_get_ppp are only
 	 * valid if the ibm,partition-performance-parameters-level
 	 * property is >= 1.
-- 
2.43.0

Re: [PATCH] pseries/lparcfg: Add resource group monitoring

[Shrikanth Hegde]

On 7/16/25 16:15, Srikar Dronamraju wrote:
> Systems can now be partitioned into resource groups. By default all
> systems will be part of default resource group. Once a resource group is
> created, and resources allocated to the resource group, those resources
> will be removed from the default resource group. If a LPAR moved to a
> resource group, then it can only use resources in the resource group.
> 
> So maximum processors that can be allocated to a LPAR can be equal or
> smaller than the resources in the resource group.
> 
> lparcfg can now exposes the resource group id to which this LPAR belongs
> to. It also exposes the number of processors in the current resource
> group. The default resource group id happens to be 0. These would be
> documented in the upcoming PAPR update.

Could you please add a link to patch on power utils on how it is being consumed?

> 
> Example of an LPAR in a default resource group
> root@ltcp11-lp3 $ grep resource_group /proc/powerpc/lparcfg
> resource_group_number=0
> resource_group_active_processors=50
> root@ltcp11-lp3 $
> 
> Example of an LPAR in a non-default resource group
> root@ltcp11-lp5 $ grep resource_group /proc/powerpc/lparcfg
> resource_group_number=1
> resource_group_active_processors=30
> root@ltcp11-lp5 $
> 
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
> Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
> ---
>   arch/powerpc/platforms/pseries/lparcfg.c | 17 ++++++++++++++---
>   1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
> index cc22924f159f..6554537984fb 100644
> --- a/arch/powerpc/platforms/pseries/lparcfg.c
> +++ b/arch/powerpc/platforms/pseries/lparcfg.c

Does MODULE_VERS need to increased?

> @@ -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)

> +		seq_printf(m, "resource_group_number=%d\n",
> +				ppp_data.resource_group_index);
> +		seq_printf(m, "resource_group_active_processors=%d\n",
> +				ppp_data.active_procs_in_resource_group);
> +	}
> +
>   	/* The last bits of information returned from h_get_ppp are only
>   	 * valid if the ibm,partition-performance-parameters-level
>   	 * property is >= 1.

Re: [PATCH] pseries/lparcfg: Add resource group monitoring

[Srikar Dronamraju]

* Shrikanth Hegde <sshegde@linux.ibm.com> [2025-08-01 19:27:22]:

> 
> On 7/16/25 16:15, Srikar Dronamraju wrote:
> > Systems can now be partitioned into resource groups. By default all
> > systems will be part of default resource group. Once a resource group is
> > created, and resources allocated to the resource group, those resources
> > will be removed from the default resource group. If a LPAR moved to a
> > resource group, then it can only use resources in the resource group.
> > 
> > So maximum processors that can be allocated to a LPAR can be equal or
> > smaller than the resources in the resource group.
> > 
> > lparcfg can now exposes the resource group id to which this LPAR belongs
> > to. It also exposes the number of processors in the current resource
> > group. The default resource group id happens to be 0. These would be
> > documented in the upcoming PAPR update.
> 
> 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.

If your query is on how resource group data is being consumed by users.
Kernel is being transparent and reporting the information from the firmware.
This information is mostly for system administrators and they would already
known this info since they would be people who would have configured the
resource groups in the first place. Kernel doesnt provide a way to configure
resource group settings. This is more of a handy way to recollect the
information, rather than any action that needs to be taken.

> 
> > 
> > Example of an LPAR in a default resource group
> > root@ltcp11-lp3 $ grep resource_group /proc/powerpc/lparcfg
> > resource_group_number=0
> > resource_group_active_processors=50
> > root@ltcp11-lp3 $
> > 
> > Example of an LPAR in a non-default resource group
> > root@ltcp11-lp5 $ grep resource_group /proc/powerpc/lparcfg
> > resource_group_number=1
> > resource_group_active_processors=30
> > root@ltcp11-lp5 $
> > 
> > Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Nicholas Piggin <npiggin@gmail.com>
> > Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
> > Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
> > ---
> >   arch/powerpc/platforms/pseries/lparcfg.c | 17 ++++++++++++++---
> >   1 file changed, 14 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
> > index cc22924f159f..6554537984fb 100644
> > --- a/arch/powerpc/platforms/pseries/lparcfg.c
> > +++ b/arch/powerpc/platforms/pseries/lparcfg.c
> 
> 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.

> 
> > @@ -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.

> 
> > +		seq_printf(m, "resource_group_number=%d\n",
> > +				ppp_data.resource_group_index);
> > +		seq_printf(m, "resource_group_active_processors=%d\n",
> > +				ppp_data.active_procs_in_resource_group);
> > +	}
> > +
> >   	/* The last bits of information returned from h_get_ppp are only
> >   	 * valid if the ibm,partition-performance-parameters-level
> >   	 * property is >= 1.
> 

-- 
Thanks and Regards
Srikar Dronamraju

Re: [PATCH] pseries/lparcfg: Add resource group monitoring

[Shrikanth Hegde]

On 8/5/25 11:13, Srikar Dronamraju wrote:
> * Shrikanth Hegde <sshegde@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?

Re: [PATCH] pseries/lparcfg: Add resource group monitoring

[Srikar Dronamraju]

* Shrikanth Hegde <sshegde@linux.ibm.com> [2025-08-06 19:49:13]:

> 
> 
> On 8/5/25 11:13, Srikar Dronamraju wrote:
> > * Shrikanth Hegde <sshegde@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

I guess, power utils patch would need a linuxppc-dev mail reference and not
vice-versa. Since this patch would sent first and the reviewers of the power
utils patch would a need a reference to this patch.

Since this patch needs to be sent first, how do I generate a url for the
second / subsequent patch?

> 
> > 
> > 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

I still dont see a reason for increasing the 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?
> 

ppp_data.active_procs_in_resource_group being 0 is valid, it means its running
on an hypervisor, that doesn't support Resource group.

if ppp_data.active_procs_in_resource_group is non zero and
ppp_data.resource_group_index is not present, then its a bug.

ppp_data.active_procs_in_resource_group can only be integers.

-- 
Thanks and Regards
Srikar Dronamraju

Re: [PATCH] pseries/lparcfg: Add resource group monitoring

[Venkat]

> On 16 Jul 2025, at 4:15 PM, Srikar Dronamraju <srikar@linux.ibm.com> wrote:
> 
> Systems can now be partitioned into resource groups. By default all
> systems will be part of default resource group. Once a resource group is
> created, and resources allocated to the resource group, those resources
> will be removed from the default resource group. If a LPAR moved to a
> resource group, then it can only use resources in the resource group.
> 
> So maximum processors that can be allocated to a LPAR can be equal or
> smaller than the resources in the resource group.
> 
> lparcfg can now exposes the resource group id to which this LPAR belongs
> to. It also exposes the number of processors in the current resource
> group. The default resource group id happens to be 0. These would be
> documented in the upcoming PAPR update.
> 
> Example of an LPAR in a default resource group
> root@ltcp11-lp3 $ grep resource_group /proc/powerpc/lparcfg
> resource_group_number=0
> resource_group_active_processors=50
> root@ltcp11-lp3 $
> 
> Example of an LPAR in a non-default resource group
> root@ltcp11-lp5 $ grep resource_group /proc/powerpc/lparcfg
> resource_group_number=1
> resource_group_active_processors=30
> root@ltcp11-lp5 $
> 
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
> Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/lparcfg.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
> index cc22924f159f..6554537984fb 100644
> --- a/arch/powerpc/platforms/pseries/lparcfg.c
> +++ b/arch/powerpc/platforms/pseries/lparcfg.c
> @@ -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)  {
> + seq_printf(m, "resource_group_number=%d\n",
> + ppp_data.resource_group_index);
> + seq_printf(m, "resource_group_active_processors=%d\n",
> + ppp_data.active_procs_in_resource_group);
> + }
> +
> /* The last bits of information returned from h_get_ppp are only
> * valid if the ibm,partition-performance-parameters-level
> * property is >= 1.
> -- 
> 2.43.0
> 

<Resending to the right thread>

Greetings!!!

Tested this patch by applying on 6.16 kernel. Build and boot was fine.

Assigned the LPAR to different RG, and with this patch, RG Index and active_procs in RG reported the correct information. Hence,

Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>

Regards,
Venkat.

Re: [PATCH] pseries/lparcfg: Add resource group monitoring

[Venkat]

Greetings!!!

Tested this patch by applying on 6.16 kernel. Build and boot was fine.

Assigned the LPAR to different RG, and with this patch, RG Index and active_procs in RG reported the correct information. Hence,

Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>

Regards,
Venkat.