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, Thanks for going through the patches/discussions.

On 8/13/26 12:20 PM, Mete Durlu wrote:
> Hi all,
> 
> All of the points raised by Ionut are about governor lacking
> certain logic for a specific arch. Considering what Shrikanth
> mentions under "Future Work";
> 
> """
> Known Limitations & Future Work
> ===============================
> ...
> - Arch specific hints and framework for it as been deferred to
>    the future.
> ...
> """
> 
> 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.

> 
> I really think we should follow the example of cpuidle
> drivers and how their framework brings together so many
> platforms under a single roof.
> 

But I remember fredric saying it isn't ideal either and he had
planned to clean it up. (Fredric, correct me if i remember it wrong)

> Thanks!
> -Mete

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.

But if the patch given in other thread is good enough for XEN, then we 
could keep it simple one file for the time being.

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.

Thoughts?