On Tue, 26 Feb 2019 at 22:52, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Tue, Feb 26, 2019 at 10:31 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > On Tue, 26 Feb 2019 at 18:50, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > > > On Tue, Feb 26, 2019 at 3:55 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > > > > > Changes in v11: > > > > - This version contains only the infrastructure changes that is needed for > > > > deployment. The PSCI/ARM changes have also been updated and tested, but I will > > > > post them separately. Still, to provide completeness, I have published a branch > > > > containing everything to a git tree [1], feel free to have a look and test. > > > > - The v10 series contained a patch, "timer: Export next wakeup time of a CPU", > > > > which has been replaced by a couple of new patches, whom reworks the existing > > > > tick_nohz_get_sleep_length() function, to provide the next timer expiration > > > > instead of the duration. > > > > - More changelogs are available per patch. > > > > > > NAK for patches [4-6/8]. > > > > > > The code as is specifically avoids calling ktime_get() from the > > > governors as that can be quite expensive, so these patches potentially > > > make things worse. > > > > Yeah, good point! What do you think about folding in a patch into the > > series, like below, and then let the cpuidle governors use it? > > It is not objectionable as it stands, but that also depends on what > the new function is used for. > > In particular, I don't really think that the menu and teo governors > need to call it at all. Well, if we are going to re-work the code as suggested in the series, then how would you suggest to get rid of the calls to ktime_get() that is introduced in patch 4 and patch5? BTW, at a closer look I am even tempted to squash patch3 to patch6 (including the part I attached earlier) as this part of the series is really a re-work of tick_nohz_get_sleep_length() and its users. > > > One questions about when CONFIG_NO_HZ_COMMON is unset for the below > > suggested code, does it make sense to "return -1" for that case, or > > should I return ktime_get()? Does it matter? > > Again, it may or may not matter depending on what the caller is going > to do with the value returned by it. Well, so far this is only for teo/menu - instead of calling ktime_get(). Any other suggestions of how to move forward here is welcome, of course! Kind regards Uffe
