[v6,0/3] Better domain idle from device wakeup patterns

Message

Lina Iyer Nov. 30, 2020, 10:50 p.m. UTC

Hi,

The v5[1] of the series brought out some interesting discussions. The
most important being is it worth adding the additional expense to all PM
domains even if no wakeup pattern is available. It seems like
maintaining a domain specific flag that the governor could check is a
generic enough option. That should disable additional overhead for
domains that do not need this feature.

Ulf suggested that we could allow wakeups only if any of the domain idle
state specifies a residency. However, we don't want to check for next
wakeup everytime the domain enters idle just because the domain
specifies an idle state with residency. This is also not desired.

Also, if the domain checks for next wakeup, should the parent domains of
the domain also check for next wakeup? And when do we set that up? These
are questions that we don't know the answers yet. So, let's enable the
domain governor only if the domain sets up the flag or when the device
in the domain specifies the next wakeup.

The previous post of the series explaining why this is a useful feature
is v5[1]. Please let me know what you think.

Thanks,
Lina

[1]. https://www.spinics.net/lists/linux-arm-msm/msg75555.html

Lina Iyer (3):
  PM / Domains: add domain feature flag for next wakeup
  PM / domains: inform PM domain of a device's next wakeup
  PM / Domains: use device's next wakeup to determine domain idle state

 drivers/base/power/domain.c          |  59 ++++++++++++++++
 drivers/base/power/domain_governor.c | 102 ++++++++++++++++++++++++---
 include/linux/pm_domain.h            |  37 ++++++++--
 3 files changed, 183 insertions(+), 15 deletions(-)

Comments

Rafael J. Wysocki Dec. 8, 2020, 5:26 p.m. UTC | #1

On Mon, Nov 30, 2020 at 11:51 PM Lina Iyer <[e-mail]> wrote:
>
> Hi,
>
> The v5[1] of the series brought out some interesting discussions. The
> most important being is it worth adding the additional expense to all PM
> domains even if no wakeup pattern is available. It seems like
> maintaining a domain specific flag that the governor could check is a
> generic enough option. That should disable additional overhead for
> domains that do not need this feature.
>
> Ulf suggested that we could allow wakeups only if any of the domain idle
> state specifies a residency. However, we don't want to check for next
> wakeup everytime the domain enters idle just because the domain
> specifies an idle state with residency. This is also not desired.
>
> Also, if the domain checks for next wakeup, should the parent domains of
> the domain also check for next wakeup? And when do we set that up? These
> are questions that we don't know the answers yet. So, let's enable the
> domain governor only if the domain sets up the flag or when the device
> in the domain specifies the next wakeup.
>
> The previous post of the series explaining why this is a useful feature
> is v5[1]. Please let me know what you think.

Ulf had comments on the previous versions, so waiting for him to
respond here, thanks!

Ulf Hansson Dec. 9, 2020, 10:36 a.m. UTC | #2

On Tue, 8 Dec 2020 at 18:26, Rafael J. Wysocki <[e-mail]> wrote:
>
> On Mon, Nov 30, 2020 at 11:51 PM Lina Iyer <[e-mail]> wrote:
> >
> > Hi,
> >
> > The v5[1] of the series brought out some interesting discussions. The
> > most important being is it worth adding the additional expense to all PM
> > domains even if no wakeup pattern is available. It seems like
> > maintaining a domain specific flag that the governor could check is a
> > generic enough option. That should disable additional overhead for
> > domains that do not need this feature.
> >
> > Ulf suggested that we could allow wakeups only if any of the domain idle
> > state specifies a residency. However, we don't want to check for next
> > wakeup everytime the domain enters idle just because the domain
> > specifies an idle state with residency. This is also not desired.
> >
> > Also, if the domain checks for next wakeup, should the parent domains of
> > the domain also check for next wakeup? And when do we set that up? These
> > are questions that we don't know the answers yet. So, let's enable the
> > domain governor only if the domain sets up the flag or when the device
> > in the domain specifies the next wakeup.
> >
> > The previous post of the series explaining why this is a useful feature
> > is v5[1]. Please let me know what you think.
>
> Ulf had comments on the previous versions, so waiting for him to
> respond here, thanks!

Yes, I will have a look, but please allow me some more time - it's a
busy period for me.

Kind regards
Uffe

Lina Iyer Dec. 9, 2020, 3:18 p.m. UTC | #3

On Wed, Dec 09 2020 at 03:37 -0700, Ulf Hansson wrote:
>On Tue, 8 Dec 2020 at 18:26, Rafael J. Wysocki <[e-mail]> wrote:
>>
>> On Mon, Nov 30, 2020 at 11:51 PM Lina Iyer <[e-mail]> wrote:
>> >
>> > Hi,
>> >
>> > The v5[1] of the series brought out some interesting discussions. The
>> > most important being is it worth adding the additional expense to all PM
>> > domains even if no wakeup pattern is available. It seems like
>> > maintaining a domain specific flag that the governor could check is a
>> > generic enough option. That should disable additional overhead for
>> > domains that do not need this feature.
>> >
>> > Ulf suggested that we could allow wakeups only if any of the domain idle
>> > state specifies a residency. However, we don't want to check for next
>> > wakeup everytime the domain enters idle just because the domain
>> > specifies an idle state with residency. This is also not desired.
>> >
>> > Also, if the domain checks for next wakeup, should the parent domains of
>> > the domain also check for next wakeup? And when do we set that up? These
>> > are questions that we don't know the answers yet. So, let's enable the
>> > domain governor only if the domain sets up the flag or when the device
>> > in the domain specifies the next wakeup.
>> >
>> > The previous post of the series explaining why this is a useful feature
>> > is v5[1]. Please let me know what you think.
>>
>> Ulf had comments on the previous versions, so waiting for him to
>> respond here, thanks!
>
>Yes, I will have a look, but please allow me some more time - it's a
>busy period for me.
>
Thank you.

-- Lina