Re: [PATCH v11 0/8] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM)

[Ulf Hansson]

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