On Wed, Oct 28, 2015 at 08:30:42AM +0530, Viresh Kumar wrote:
> These are the last memories I have around upstreaming this governor:
> http://marc.info/?l=linux-kernel&m=132867057910479&w=2
>
> Has anything changed after that? Or we decided to go ahead with it and
> upstream ?
Urgh, I thought we were trying to kill all the various governors by
integrating the lot with the scheduler !?
On 11/02/2015 06:02 AM, Peter Zijlstra wrote:
> On Wed, Oct 28, 2015 at 08:30:42AM +0530, Viresh Kumar wrote:
>> These are the last memories I have around upstreaming this governor:
>> http://marc.info/?l=linux-kernel&m=132867057910479&w=2
>>
>> Has anything changed after that? Or we decided to go ahead with it and
>> upstream ?
>
> Urgh, I thought we were trying to kill all the various governors by
> integrating the lot with the scheduler !?
That's the goal but it may be a while. There are major unanswered questions IMO about the viability of replacing all the governers with a single scheduler-driven implementation. Is per-entity load tracking responsive enough to drive CPU frequency? Can we replicate the functionality available and being used today with the proposed design? These aren't necessarily showstoppers but they could require considerable extra work (and debate).
If we move forward without ensuring these concerns are addressed I believe it would make things even worse than they are now since there will be people/vendors remaining behind on cpufreq governors, forward porting them if necessary, and there will be the fundamentally different sched-driven solution to support and maintain as well.
Having the interactive governor in the tree would help in the evaluation and comparison process, and also immediately address a widely used component being out of tree.