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

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

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.

Thank you!