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

From: Rafael J. Wysocki
Date: Tue Feb 26 2019 - 17:11:35 EST


On Tue, Feb 26, 2019 at 11:06 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>
> 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.

Which is unnecessary IMO - see my reply to patch [7/8].