On Tue, 10 Jun 2014, Peter Zijlstra wrote: > So the current cpufreq stuff is terminally broken in too many ways; its > sampling, so it misses a lot of changes, its strictly cpu local, so it > completely misses SMP information (like the migrations etc..) > > If we move a 50% task from CPU1 to CPU0, a sampling thing takes time to > adjust on both CPUs, whereas if its scheduler driven, we can instantly > adjust and be done, because we _know_ what we moved.
Incidentally I submitted a LWN article highlighting those very issues and the planned remedies. No confirmation of a publication date though. > Now some of that is due to hysterical raisins, and some of that due to > broken hardware (hardware that needs to schedule in order to change its > state because its behind some broken bus or other). But we should > basically kill off cpufreq for anything recent and sane. EVen if some change has to happen through a kernel thread, you're still far better with the scheduler requesting this change proactively than waiting for both the cpufreq governor to catch up with the load and then wait for the freq change thread to be scheduled. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
