On 01-06-16, 18:37, Rafael J. Wysocki wrote:
On Wednesday, June 01, 2016 04:12:43 PM Viresh Kumar wrote:
On 01-06-16, 00:50, Rafael J. Wysocki wrote:
I'm not particularly liking this due to the possible confusion that may result from it.
I have gotten rid of most of it now in V2.
Perhaps we can require drivers implementing ->fast_switch to sort their frequency tables to start with?
I wasn't *only* concerned about the fast-switch case, but the case of normal governors that we use today. After all that's what everybody is using right now.
Sure, but the "to start with" part of my question was essential.
We can make that a requirement, but I am not sure if that will help us much. I want to use the same routines for the target_index() callbacks and the fast_switch() ones.
And that's what I have done in V2 of this series.
The ordering didn't matter before, so drivers may do silly things related to it
Yes they do and that's why I couldn't get rid of policy->freq_table for now. Though I have plans to sort that out.
and those may break if we try to change the rules wholesale.
Yes. But the V2 of this series isn't making any such change. Just that we are keeping a backup sorted table (which drivers wouldn't know about) to find the right match. We will still keep passing the index to their *unsorted* tables in target_index() for example.
In turn, if the (prospective) ->fast_switch users are required to clean up their stuff while working on implementig it, we could avoid that breakage, or at least some of it.
I understand your point of view, but I think V2 is sorting all that out without breaking anything at all.
Or maybe make the core check whether or not the table is sorted
Platforms are already broken for this, and so wouldn't be possible to check for existing governors.
I really don't know what you wanted to say here.
Oh, I was saying that existing drivers of course don't guarantee that today, and if we want to make the search fast for existing governors, we wouldn't be able to do it for all.
Anyway, I agree that using one ordering would be cleaner, but I'm sort of concerned about how painful the switch-over may be to the users.
They wouldn't notice at all. V2 handles that properly.