On Tue, Feb 26, 2019 at 11:06 PM Ulf Hansson <ulf.hans...@linaro.org> wrote: > > On Tue, 26 Feb 2019 at 22:52, Rafael J. Wysocki <raf...@kernel.org> wrote: > > > > On Tue, Feb 26, 2019 at 10:31 PM Ulf Hansson <ulf.hans...@linaro.org> wrote: > > > > > > On Tue, 26 Feb 2019 at 18:50, Rafael J. Wysocki <raf...@kernel.org> wrote: > > > > > > > > On Tue, Feb 26, 2019 at 3:55 PM Ulf Hansson <ulf.hans...@linaro.org> > > > > 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.
Which is unnecessary IMO - see my reply to patch [7/8].
