Dave Jones <davej@xxxxxxxxxx> writes: > I think exposing absolute frequencies to applications is a mistake. > (And one that the core cpufreq made a long time ago). How is an application > to decide what to set it to without knowledge of the hardware it's > running on ? Abstracting the CPU frequency was briefly discussed previously. Computing performance is affected by many factors, not just CPU frequency. My view is that the actual frequency values for a given use case are likely to be very system specific (CPU, memory etc). The values would probably come from a tuning excercise and would be configurable parameters of applications. > I much prefer the idea that was mentioned a few weeks ago during the > discussion with Peter Zijlstra about cpufreq being more connected to > the scheduler, and essentially having per-process governors. > > Each process gets a /proc/self/power-policy > This can be 'performance' 'power-save' or 'ondemand' > - A global sysfs knob sets the default new processes get. > - Processes can adjust it themselves if desired. > - There's no need for a system-wide governor any more. > > There are some open questions about how this could work. > > - A list of rules for desired behaviour when performing state changes > when switching between tasks with different policies is needed. > > - We don't want to be doing power transitions every context switch, > or switching overhead will be brutal. > So some kind of lazy state changing may be necessary. > > - For 'ondemand', when would the scheduler decide to ramp up/down > the speed ? > > Dave I think better power/perf requests from applications to kernel are indeed sorely needed. However, if we are going to construct application oriented power/performance requests, I think something else than performance/powersave/ondemand might be more appropriate. For a fixed hardware platform, an application might well be tuned to know very well the minimum and maximum levels of CPU frequency that it needs in certain situation in order to meet the required responsiveness and/or consume minimum amount of energy. I think performance vs power-save is unnecessarily coarse setting. The big problem I see with application oriented metrics is that there are so many of them. I'd rather keep this kind of complexity outside the kernel. To me it feels easier to start from the hardware knobs that we can control, since - in the end - those are the knobs that the kernel needs to control. And we need consolidation of requests from multiple applications, but to me exposing hardware oriented parameters towards the user space is not a problem as such. --Antti -- 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
