* Saravana Kannan <skannan@xxxxxxxxxxxxxx> wrote: > When you say accommodate all hardware, does it mean we will > keep around CPUfreq and allow attempts at improving it? Or we > will completely move to scheduler based CPU freq scaling, but > won't try to force atomicity? Say, may be queue up a > notification to a CPU driver to scale up the frequency as soon > as it can? I don't think we should (or even could) force atomicity - we adapt to whatever the hardware can do. But the design should be directed at systems where frequency changes can be done in a reasonably fast manner. That is what he future is - any change we initiate today takes years to reach actual products/systems. > IMHO, I think the problem with CPUfreq and its dynamic > governors today is that they do a timer based sampling of the > CPU load instead of getting some hints from the scheduler when > the scheduler knows that the load average is quite high. Yes - that is one of the "frequency changes are slow" assumptions - which is wrong. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
