On Thu, Nov 30, 2017 at 2:00 AM, Li, Aubrey <aubrey...@linux.intel.com> wrote: > Hi, > > Thanks Rafael's comments against V2. I'd like to ping here to see which > direction this proposal should go and what fundamental change this proposal > should make. > > I'm also open to any suggestions if my proposal is not on the right way.
To me (and I discussed that with Peter briefly last month in Prague) the way to go would be to avoid stopping the scheduler tick until we are entirely sure that it should be stopped. Which is when the governor (any governor BTW, not just menu) chooses the target idle state for the CPU and the target residency of that state is long enough for the tick to be stopped ("long enough" here means that if the tick is not stopped, the time spent by the CPU in the target idle state will be shorter than the target residency). Note that this is totally independent on what governor is used and it doesn't involve any "refinements" or "improvements" of the prediction whatever. Of course, for the governor to make the state selection, it generally will have to know when the next non-tick timer is going to expire and getting that information to it will require some effort. Thanks, Rafael