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.
