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!
