Hi Peter,
thanks a lot for the fast reply! :)
On 05/05/15 10:00, Peter Zijlstra wrote:
On Mon, May 04, 2015 at 03:10:41PM -0700, Michael Turquette wrote:
This policy is implemented using the cpufreq governor interface for two main reasons:
- re-using the cpufreq machine drivers without using the governor
interface is hard.
- using the cpufreq interface allows us to switch between the
scheduler-driven policy and legacy cpufreq governors such as ondemand at run-time. This is very useful for comparative testing and tuning.
Urgh,. so I don't really like that. It adds a lot of noise to the system. You do the irq work thing to kick the cpufreq threads which do their little thing -- and their wakeup will influence the cfs accounting, which in turn will start the whole thing anew.
Right, we introduce some overhead, but in the end it should be less or at least similar to what we already have today with ondemand, for example. The idea here is that we should trigger this kthread wrapper only when it is really needed, and maybe reduce the things it needs to do. The irq work thing is one way we could do it from wherever we want to.
Regarding cfs accounting, the bad trick is that we run these kthreads with fifo. One reason is that we expect them to run quickly and we usually want them to run as soon as they are woken up (possibly preempting the task for which they are adapting the frequency). Of course we'll have the same accounting problem within RT, but maybe we could associate some special flag to them and treat them differently. Or else we could just realize that we need this kind of small wrapper tasks, of which we should know the behaviour of, and live with that.
Anyway, I'm currently experimenting in driving this thing a bit differently from what we have in this patchset. I'm trying to reduce the need to trigger the whole machinery to the least. Do you think is still valuable to give it a look?
I would really prefer you did a whole new system with directly invoked drivers that avoid the silly dance. Your 'new' ARM systems should be well capable of that.
Right, this thing is maybe not the cleanest solution we could come up with, and how 'new' ARM systems will work may help us designing a better one, but I'm not sure of what we can really do about today systems, though. We of course need to support them (and for few years I guess) and we would also like to have an event-driven solution to drive OPP selection from the scheduler at the same time.
From what I can tell, this "non-cpufreq" new system will probably have
to re-implement what current drivers are doing, and it will still have to sleep during freq changes (at least for ARM). This will require some asynch way of doing the freq changes, which is what the kthread solution is already doing.
Best,
- Juri
You can still do 2 if you create a cpufreq off switch. You can then either enable the sched one or the legacy cpufreq -- or both if you want a trainwreck ;-)
As to the drivers, they're mostly fairly small and self contained, it should not be too hard to hack them up to work without cpufreq.