Hi Shrikanth,

Le 25/11/2025 à 03:39, Shrikanth Hegde a écrit :

Hi Greg.

On 11/24/25 10:35 PM, Greg KH wrote:

quoted

On Wed, Nov 19, 2025 at 06:14:32PM +0530, Shrikanth Hegde wrote:

quoted

Detailed problem statement and some of the implementation choices were
discussed earlier[1].

[1]: https://eur01.safelinks.protection.outlook.com/? 
url=https%3A%2F%2Flore.kernel.org%2Fall%2F20250910174210.1969750-1- 
sshegde%40linux.ibm.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cc7e5a5830fcb4c796d4808de2bcbe09d%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638996351808032890%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cV8RTPdV3So1GwQ9uVYgUuGxSfxutSezpaNBq6RYn%2FI%3D&reserved=0

This is likely the version which would be used for LPC2025 discussion on
this topic. Feel free to provide your suggestion and hoping for a 
solution
that works for different architectures and it's use cases.

All the existing alternatives such as cpu hotplug, creating isolated
partitions etc break the user affinity. Since number of CPUs to use 
change
depending on the steal time, it is not driven by User. Hence it would be
wrong to break the affinity. This series allows if the task is pinned
only paravirt CPUs, it will continue running there.

Changes compared v3[1]:

There is no "v" for this series :(

I thought about adding v1.

I made it as PATCH from RFC PATCH since functionally it should
be complete now with arch bits. Since it is v1, I remember usually 
people send out without adding v1. after v1 had tags such as v2.

I will keep v2 for the next series.

But you are listing changes compared to v3, how can it be a v1 ? 
Shouldn't it be a v4 ? Or in reality a v5 as you already sent a v4 here [1].

[1] 
https://lore.kernel.org/all/20251119062100.1112520-1-sshegde@linux.ibm.com/ (local)

Christophe