Re: [PATCH] Re: [PATCH v10 00/12] sched, steal_governor: Introduce preferred CPUs and steal-driven vCPU backoff

[Shrikanth Hegde <sshegde@linux.ibm.com>]

Hi Mete,

On 8/14/26 2:52 PM, Mete Durlu wrote:
> On 13/08/2026 13:12, Shrikanth Hegde wrote:
>> Hi Mete, Thanks for going through the patches/discussions.
>>
>> On 8/13/26 12:20 PM, Mete Durlu wrote:
> 
> ...
> 
>>>
>>> I think all of these points can be addressed better if
>>> Xen used said framework and implemented their own governor
>>> module. That way we wouldn't see an overinflated single
>>> steal_governor but instead nicely separated arch/platform
>>> specific ones, that are tailored best for their needs.
>>> The current implementation could be the fallback option
>>> if platform does not implement their own and would also
>>> serve as an example.
>>
>> For now, I prefer adding a defensive check for dom0
>> and keep the driver simple.
> 
> Fair enough.
> 
> ...
>> I prefer we defer the arch specific hooks for now, until there is a 
>> need for one. If you guys insist it should be done, then i can start 
>> looking at cpuidle framework. But it will be a bigger rework.
> 
> s390 plans to adopt and start using the preferred CPU approach along

That's nice. I am happy to hear that it will come in soon.

> with the governor. The concern is that there are some enhancements
> planned which would not really fit into the current governor.
> 

> Later on, s390 will probably introduce its own governor module and
> for that I was hoping that there would be a framework similar to
> cpuidle drivers.
> 


I was skimming through cpuidle logic. The problem with steal_governor is that,
it is not a built in module. For loadable modules, core_initcall and
device_initcall will evaluate to the same thing,
which makes a direct cpuidle-like approach tricky.

However, as you mentioned, we just need a common infrastructure for the
init/exit/methods leaving the decision-making to the arch.
I've thought of a few ways we can cleanly pull this off post-merge:

1. ifdefs and ops function pointers:
   We define a struct of function pointers and a bit ifdefs for init etc.
   The core initializes ops to default or s390 depending on the config.

2. __weak Functions:
   We define the main routines as __weak and let s390 simply override them.
   This is the lowest boilerplate, though its usage is not preferred.

3. Multiple Modules (The cpuidle module approach):
   We split it into steal_governor_core.ko and steal_governor_s390.ko.
   The core exports a steal_governor_register_driver() symbol, and the
   s390 module registers its specific ops when loaded.
   However, this would still need elements of the first approach to
   handle Dom0-like cases natively.

Depending on users and adoption of the feature by different archs,
we can go about it which is more appropriate.


> What I mean essentially is a common infrastructure to initialize
> the basics required for the preferred CPUs management and maybe
> the update loop mechanism. That should ideally leave just the
> decision making part to the individual arch/platform to implement.
> I imagine the whole thing being much more simpler than cpuidle
> drivers as it had a lot more moving parts involved.
> 
> ...
> 
>> If the driver eventually outgrows a single file, we can work on a 
>> modular framework post-merge. But for now, let's keep it simple and 
>> get the simple version upstream.
> 
> I understand the concern and I think it's the right approach to keep
> it simple initially.

Thanks. Yes. Lets keep it simple for now.

Once this series is merged, We can work out the
framework for s390-specific enhancements.

> 
> Thank you!
> 

PS: I will wait for few days to hear from Ionut/Yury on the patch addressing
all the comments. If i don't hear anything back, i will post v11 next week.