Messages in this thread | | | Date | Fri, 8 Nov 2019 10:39:19 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH v2] cpuidle: Use nanoseconds as the unit of time |
| |
On Fri, Nov 08, 2019 at 02:44:13AM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 7, 2019 at 3:25 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > Currently, the cpuidle subsystem uses microseconds as the unit of > > time which (among other things) causes the idle loop to incur some > > integer division overhead for no clear benefit. > > > > In order to allow cpuidle to measure time in nanoseconds, add two > > additional fields, exit_latency_ns and target_residency_ns, to > > represent the exit latency and target residency of an idle state > > in nanoseconds, respectively, to struct cpuidle_state_usage and > > initialize them with the help of the corresponding values in > > microseconds provided by drivers. In addition to that, change > > cpuidle_governor_latency_req() to return the idle state exit > > latency constraint in nanoseconds. > > > > With that, meeasure idle state residency (last_residency_ns in > > struct cpuidle_device and time_ns in struct cpuidle_driver) in > > nanoseconds and update the cpuidle core and governors accordingly. > > > > However, the menu governor still computes typical intervals in > > microseconds to avoid integer overflows. > > Since this addresses all of the comments received by the RFC version > that was posted over a month ago and I don't see any more issues with > it, I'm tempted to simply queue it up for 5.5 unless somebody sees a > good enough reason why that would be a bad idea.
Nah, have at.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
| |