On Thursday 17 Oct 2019 at 11:50:15 (+0200), Peter Zijlstra wrote: > Now, the thing is, we use map_util_freq() in more places, and should we > not reflect this increase in C for all of them? That is, why is this > patch changing get_next_freq() and not map_util_freq(). > > I don't think that question is answered in the Changelogs. > > Exactly because it does change the energy consumption (it must) should > that not also be reflected in the EAS logic?
Right that shouldn't hurt and keep things consistent. That probably won't have a huge impact in practice (the boost should be != 0 only when the util signals haven't converged IIUC, which is a case where the EAS calculation is already 'wrong' anyway), but that still feels like the right thing to do. > I'm still thinking about the exact means you're using to raise C; that > is, the 'util - util_est' as cost_margin. It hurts my brain still. +1 ... Thanks, Quentin
