cpufreq modules' performance hooks are never used

[madmax]

I was adding my model to intel_pstates (the only current cpufreq module) list of supported cpus, included some tracing and saw that, apart from the initial setting of performance mode, no change happened ever.

cpufreq modules have three specific hooks: cpu_set_scheduler_mode, increase_cpu_performance and decrease_cpu_performance.

The first one can be triggered through ProcessController, but that's only a policy change and in intel_pstates case it doesn't even adjust frequency (I guess that if everything was working, one of the other hooks would be called sooner than later and the new policy would be taken into account).

The other two are called to change the performance level from ​_RequestPerformanceLevel in scheduler_cpu.cpp, which is called from ​TrackActivity, but only when we are tracking the cpu (gTrackCPULoad).

increase_cpu_performance is also called from the scheduler initialization as ​a test to activate cpu tracking. I guess tracking doesn't make sense if you are not going to use the data.

Now we have a problem. That's the only place where tracking is set. It is called from ​scheduler_init, which is called from ​kernel start, and by that time we don't have cpufreq modules yet (they are loaded from a thread spawned a bit later: ​spawn -> ​main2 -> ​cpu_init_post_modules). So ​increase_cpu_performance returns B_NOT_SUPPORTED and gTrackCPULoad stays false.

[korli]

see ​https://review.haiku-os.org/c/haiku/+/3216

[madmax]

That (after adding a declaration for scheduler_update_policy in both cpu.cpp and scheduler.cpp) do indeed call the hooks, thank you.

Now, the chosen states... I only saw the lowest one (as measured in frequency by sysinfo) once, normally changing between 8 and 10 (from a range of 7..16) when idle, never saw more than 12 even with all cpus at 100%, and all the cpus were always in the same state even when having just one at 100% load and the rest idle.

But I guess that's a different issue and this ticket can be closed with that patch.

[korli]

Fixed in hrev54575

[nielx]

Assign fix to milestone:R1/beta3, as it looks like this fix will be part of that release.

As we started with the previous beta, we would like to use the Milestone field for fixed tickets to log from which release the improvement will be out. Therefore it is very much appreciated to assign the milestone when closing a ticket as fixed.