Big changes here. I was never comfortable with all those for loops,
especially as the iteration is over the same data again and again for each
CPU you had in a single poll, an O(n^2) outcome to frequency scaling.
Correct me if I'm wrong but the way that do_dbs_timer runs this is exactly
what the outcome is?
Anyway, the approach I use is to assume by default no CPU's exist and it sets
the requested_freq to zero as a kind of flag, the reasoning is in the source
;) If the CPU is queried and requested_freq is zero then it initialises the
variable to current_freq and then continues as if nothing happened which
should be the same net effect as before?
I'm guessing this is going to be the controversial patch but if I'm correct
this sort of thing might want to be applied to ondemand too?
All these changes should make cpufreq_conservative safe in regards to the x86
for_each_cpu cpumask.h changes and whatnot.
Signed-off-by: Alexander Clouter <[email protected]>