Re: [PATCH 5/5] intel_idle: Add S0ix validation

[dbasehore .]

On Sat, Jun 4, 2016 at 5:22 AM, Alan  wrote:
>> I would expect those IP blocks to do nothing and not block lower power
>> states if the firmware is not loaded. If that is not the case, I think
>> that should be fixed such that those lower power states are at least
>> available during suspend (if not during runtime). If your Skylake+
>> system is not entering S0ix during freeze, I consider that a bug that
>> needs to be addressed.
>
> You would assume wrongly. Several parts of the system do their own
> power management so if present need to have a driver loaded. Graphics
> is the example everyone is familiar with but ADSP audio and ISH are two
> others.

Okay, I remember running into this with the display actually.

>
>> configs, that's their decision. As I said, this does nothing in the
>> !CONFIG_INTEL_PMC_CORE case, but if a finer level config is warranted,
>> I can add that.
>
> IMHO it belongs as a config item because it has a power cost, and you
> can't turn it off without enabling debugfs when it's compiled in.
>

It could also be default off. It's not a lot of code being added, so
it could just be part of the Intel Idle driver.

After thinking about it, I plan on moving to exponential back off for
the freeze time (1, 10, 100, 1000 seconds). This way, the power impact
won't be measurable, yet it will still catch errors. There will just
be a sysfs entry added to the cpuidle node to enable/disable the
feature. The feature will be turned off by default.

>> I would prefer if others used this more, since there would be better
>> debug coverage and I would have to fix fewer bugs.
>
> I'd be more concerned about getting 10,000 emails bisecting the warning
> to your commit 8)
>
> Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[dbasehore .]

On Sat, Jun 4, 2016 at 5:22 AM, Alan  wrote:
>> I would expect those IP blocks to do nothing and not block lower power
>> states if the firmware is not loaded. If that is not the case, I think
>> that should be fixed such that those lower power states are at least
>> available during suspend (if not during runtime). If your Skylake+
>> system is not entering S0ix during freeze, I consider that a bug that
>> needs to be addressed.
>
> You would assume wrongly. Several parts of the system do their own
> power management so if present need to have a driver loaded. Graphics
> is the example everyone is familiar with but ADSP audio and ISH are two
> others.

Okay, I remember running into this with the display actually.

>
>> configs, that's their decision. As I said, this does nothing in the
>> !CONFIG_INTEL_PMC_CORE case, but if a finer level config is warranted,
>> I can add that.
>
> IMHO it belongs as a config item because it has a power cost, and you
> can't turn it off without enabling debugfs when it's compiled in.
>

It could also be default off. It's not a lot of code being added, so
it could just be part of the Intel Idle driver.

After thinking about it, I plan on moving to exponential back off for
the freeze time (1, 10, 100, 1000 seconds). This way, the power impact
won't be measurable, yet it will still catch errors. There will just
be a sysfs entry added to the cpuidle node to enable/disable the
feature. The feature will be turned off by default.

>> I would prefer if others used this more, since there would be better
>> debug coverage and I would have to fix fewer bugs.
>
> I'd be more concerned about getting 10,000 emails bisecting the warning
> to your commit 8)
>
> Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[Alan]

> I would expect those IP blocks to do nothing and not block lower power
> states if the firmware is not loaded. If that is not the case, I think
> that should be fixed such that those lower power states are at least
> available during suspend (if not during runtime). If your Skylake+
> system is not entering S0ix during freeze, I consider that a bug that
> needs to be addressed.

You would assume wrongly. Several parts of the system do their own
power management so if present need to have a driver loaded. Graphics
is the example everyone is familiar with but ADSP audio and ISH are two
others.

> configs, that's their decision. As I said, this does nothing in the
> !CONFIG_INTEL_PMC_CORE case, but if a finer level config is warranted,
> I can add that.

IMHO it belongs as a config item because it has a power cost, and you
can't turn it off without enabling debugfs when it's compiled in.

> I would prefer if others used this more, since there would be better
> debug coverage and I would have to fix fewer bugs.

I'd be more concerned about getting 10,000 emails bisecting the warning
to your commit 8)

Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[Alan]

> I would expect those IP blocks to do nothing and not block lower power
> states if the firmware is not loaded. If that is not the case, I think
> that should be fixed such that those lower power states are at least
> available during suspend (if not during runtime). If your Skylake+
> system is not entering S0ix during freeze, I consider that a bug that
> needs to be addressed.

You would assume wrongly. Several parts of the system do their own
power management so if present need to have a driver loaded. Graphics
is the example everyone is familiar with but ADSP audio and ISH are two
others.

> configs, that's their decision. As I said, this does nothing in the
> !CONFIG_INTEL_PMC_CORE case, but if a finer level config is warranted,
> I can add that.

IMHO it belongs as a config item because it has a power cost, and you
can't turn it off without enabling debugfs when it's compiled in.

> I would prefer if others used this more, since there would be better
> debug coverage and I would have to fix fewer bugs.

I'd be more concerned about getting 10,000 emails bisecting the warning
to your commit 8)

Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[dbasehore .]

On Thu, Jun 2, 2016 at 12:53 PM, One Thousand Gnomes
 wrote:
>> How would this spuriously trigger during boot? This code is only run
>> during freeze. If there's some issue with not entering S0ix before a
>> module or firmware is loaded, it's better to not use suspend to idle
>> until those are in place.
>
> Ok yes you are correct it's not likely to trigger during boot (although
> if you close the lid during boot...)
>
>> I'm not familiar with the ISH driver. How does it prevent entry into
>> S0ix? I would argue that you don't want to use suspend to idle on a
>> Skylake system that can't enter S0ix and instead use suspend to RAM.
>
> Several IP blocks on the systems do their own power management if present
> and enabled by the firmware. If they do not have drivers loaded then you
> will not be able to enter some power states. Thus you'll now get warnings
> if you try to freeze such a system and those warnings are not themselves
> terribly helpful to a user.

I would expect those IP blocks to do nothing and not block lower power
states if the firmware is not loaded. If that is not the case, I think
that should be fixed such that those lower power states are at least
available during suspend (if not during runtime). If your Skylake+
system is not entering S0ix during freeze, I consider that a bug that
needs to be addressed.

>
> It's a good debug feature, but it doesn't belong anywhere but debug menus
> and off by default. If you want to ship it enabled in ChromeOS for
> product fine, but I don't think it belongs on for everywhere and
> everything.

If other Linux distributions choose not to enable it in their kernel
configs, that's their decision. As I said, this does nothing in the
!CONFIG_INTEL_PMC_CORE case, but if a finer level config is warranted,
I can add that.

I would prefer if others used this more, since there would be better
debug coverage and I would have to fix fewer bugs.

>
> Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[dbasehore .]

On Thu, Jun 2, 2016 at 12:53 PM, One Thousand Gnomes
 wrote:
>> How would this spuriously trigger during boot? This code is only run
>> during freeze. If there's some issue with not entering S0ix before a
>> module or firmware is loaded, it's better to not use suspend to idle
>> until those are in place.
>
> Ok yes you are correct it's not likely to trigger during boot (although
> if you close the lid during boot...)
>
>> I'm not familiar with the ISH driver. How does it prevent entry into
>> S0ix? I would argue that you don't want to use suspend to idle on a
>> Skylake system that can't enter S0ix and instead use suspend to RAM.
>
> Several IP blocks on the systems do their own power management if present
> and enabled by the firmware. If they do not have drivers loaded then you
> will not be able to enter some power states. Thus you'll now get warnings
> if you try to freeze such a system and those warnings are not themselves
> terribly helpful to a user.

I would expect those IP blocks to do nothing and not block lower power
states if the firmware is not loaded. If that is not the case, I think
that should be fixed such that those lower power states are at least
available during suspend (if not during runtime). If your Skylake+
system is not entering S0ix during freeze, I consider that a bug that
needs to be addressed.

>
> It's a good debug feature, but it doesn't belong anywhere but debug menus
> and off by default. If you want to ship it enabled in ChromeOS for
> product fine, but I don't think it belongs on for everywhere and
> everything.

If other Linux distributions choose not to enable it in their kernel
configs, that's their decision. As I said, this does nothing in the
!CONFIG_INTEL_PMC_CORE case, but if a finer level config is warranted,
I can add that.

I would prefer if others used this more, since there would be better
debug coverage and I would have to fix fewer bugs.

>
> Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[One Thousand Gnomes]

> How would this spuriously trigger during boot? This code is only run
> during freeze. If there's some issue with not entering S0ix before a
> module or firmware is loaded, it's better to not use suspend to idle
> until those are in place.

Ok yes you are correct it's not likely to trigger during boot (although
if you close the lid during boot...)

> I'm not familiar with the ISH driver. How does it prevent entry into
> S0ix? I would argue that you don't want to use suspend to idle on a
> Skylake system that can't enter S0ix and instead use suspend to RAM.

Several IP blocks on the systems do their own power management if present
and enabled by the firmware. If they do not have drivers loaded then you
will not be able to enter some power states. Thus you'll now get warnings
if you try to freeze such a system and those warnings are not themselves
terribly helpful to a user.

It's a good debug feature, but it doesn't belong anywhere but debug menus
and off by default. If you want to ship it enabled in ChromeOS for
product fine, but I don't think it belongs on for everywhere and
everything.

Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[One Thousand Gnomes]

> How would this spuriously trigger during boot? This code is only run
> during freeze. If there's some issue with not entering S0ix before a
> module or firmware is loaded, it's better to not use suspend to idle
> until those are in place.

Ok yes you are correct it's not likely to trigger during boot (although
if you close the lid during boot...)

> I'm not familiar with the ISH driver. How does it prevent entry into
> S0ix? I would argue that you don't want to use suspend to idle on a
> Skylake system that can't enter S0ix and instead use suspend to RAM.

Several IP blocks on the systems do their own power management if present
and enabled by the firmware. If they do not have drivers loaded then you
will not be able to enter some power states. Thus you'll now get warnings
if you try to freeze such a system and those warnings are not themselves
terribly helpful to a user.

It's a good debug feature, but it doesn't belong anywhere but debug menus
and off by default. If you want to ship it enabled in ChromeOS for
product fine, but I don't think it belongs on for everywhere and
everything.

Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[dbasehore .]

On Thu, Jun 2, 2016 at 6:23 AM, One Thousand Gnomes
 wrote:
>
> There are plenty of Skylake configurations where at the moment you won't
> get s0ix entry because the ISH driver is not yet merged. Spamming those
> users with useless messages is not helpful. Likewise on systems with
> modular kernels your warning may spuriously trigger during boot until the
> ISH, i915 and audio modules and firmware have loaded and are active. I
> know Chrome doesn't like modules but the rest of us do !

How would this spuriously trigger during boot? This code is only run
during freeze. If there's some issue with not entering S0ix before a
module or firmware is loaded, it's better to not use suspend to idle
until those are in place.

I'm not familiar with the ISH driver. How does it prevent entry into
S0ix? I would argue that you don't want to use suspend to idle on a
Skylake system that can't enter S0ix and instead use suspend to RAM.

>
> I'm also a bit at a loss to understand why anyone needs this except
> validation engineers for Chrome products and kernel hackers doing
> debug. It seems a bit odd to burden the entire world with a pile of
> checks they can't use that cost even 0.3% of power (that's 15 minutes on
> an 8 hour battery multiplied by every Skylake user!).
>
> Having to have debugfs present to turn it off, but not to use it is also
> a bit weird...
>
> IMHO this should be one of the hacking/kernel debug options and not even
> compiled into normal kernels.
>
> Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[dbasehore .]

On Thu, Jun 2, 2016 at 6:23 AM, One Thousand Gnomes
 wrote:
>
> There are plenty of Skylake configurations where at the moment you won't
> get s0ix entry because the ISH driver is not yet merged. Spamming those
> users with useless messages is not helpful. Likewise on systems with
> modular kernels your warning may spuriously trigger during boot until the
> ISH, i915 and audio modules and firmware have loaded and are active. I
> know Chrome doesn't like modules but the rest of us do !

How would this spuriously trigger during boot? This code is only run
during freeze. If there's some issue with not entering S0ix before a
module or firmware is loaded, it's better to not use suspend to idle
until those are in place.

I'm not familiar with the ISH driver. How does it prevent entry into
S0ix? I would argue that you don't want to use suspend to idle on a
Skylake system that can't enter S0ix and instead use suspend to RAM.

>
> I'm also a bit at a loss to understand why anyone needs this except
> validation engineers for Chrome products and kernel hackers doing
> debug. It seems a bit odd to burden the entire world with a pile of
> checks they can't use that cost even 0.3% of power (that's 15 minutes on
> an 8 hour battery multiplied by every Skylake user!).
>
> Having to have debugfs present to turn it off, but not to use it is also
> a bit weird...
>
> IMHO this should be one of the hacking/kernel debug options and not even
> compiled into normal kernels.
>
> Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[dbasehore .]

On Thu, Jun 2, 2016 at 6:23 AM, One Thousand Gnomes
 wrote:
> On Thu, 2 Jun 2016 11:25:05 +0200
> Peter Zijlstra  wrote:
>
>> On Wed, Jun 01, 2016 at 09:33:29PM -0700, dbaseh...@chromium.org wrote:
>> > +/*
>> > + * Default chosen to have <= 1% power increase while allowing fast 
>> > detection of
>> > + * SLP S0 entry errors. Waking up 10 times a second shows ~30% increase in
>> > + * system power on Skylake Y. Waking up once every 10 seconds is
>> > + * indistinguishable from not waking up at all (as ~0.3% power increase 
>> > would
>> > + * be). Any reasonable power increases above this will not be visible to 
>> > the
>> > + * user.
>> > + */
>> > +#define DEFAULT_SLP_S0_SECONDS 10
>>
>> So I don't think anybody waits for 10 seconds to see if suspend worked.
>> After 10 seconds its in the bag and I'm out the door.
>>
>> Then what?
>>
>>
>> Why can't you fire a single timer after 0.5 seconds to see if you hit
>> C10 and leave it at that? What's the point any further wakeup, if you
>> know you hit C10, you're good continue on.

That will take care of most of the problems I have seen, but that
doesn't handle everything. Say your audio codec is misconfigured and
causes an interrupt storm when you plug in headphones. The irq handler
won't run, but it could still wake up the system repeatedly and
prevent entry into S0ix.

If this fails, it's not expected that the user catch and handle it,
unless he/she uses "echo freeze > /sys/power/state" to suspend to
idle. It's intended that whatever daemon in user space handles power
state transitions will catch the error and either retry, suspend to
RAM, or shut down the system.

What could happen is we could wake up after 1 second the first time,
then wake up at a slp_s0_seconds after that. This will allow us to
fail faster, still catch issues that happen later, and increase
DEFAULT_SLP_S0_SECONDS to something longer.

>
> There are plenty of Skylake configurations where at the moment you won't
> get s0ix entry because the ISH driver is not yet merged. Spamming those
> users with useless messages is not helpful. Likewise on systems with
> modular kernels your warning may spuriously trigger during boot until the
> ISH, i915 and audio modules and firmware have loaded and are active. I
> know Chrome doesn't like modules but the rest of us do !
>
> I'm also a bit at a loss to understand why anyone needs this except
> validation engineers for Chrome products and kernel hackers doing
> debug. It seems a bit odd to burden the entire world with a pile of
> checks they can't use that cost even 0.3% of power (that's 15 minutes on
> an 8 hour battery multiplied by every Skylake user!).

15 minutes is 4% of 8 hours, but let's take a system that has 8 hours
of battery life for use and 10 days of suspend to idle. 0.3% of 10
days is < 1 hour. That's only for suspend time, though. A user could
lose 1.5 minutes of use, but that's only if the user left his or her
machine suspended for 10 days. I'll probably add the single early wake
that I mentioned before and change this to 100 seconds. At that point,
we're looking at 0.03% power increase, which is < 9 seconds of lost
use for 10 days of suspend to idle.

>
> Having to have debugfs present to turn it off, but not to use it is also
> a bit weird...

I could look into putting this into the cpuidle sysfs.

>
> IMHO this should be one of the hacking/kernel debug options and not even
> compiled into normal kernels.

This patch isn't only about finding the bugs, but doing something more
graceful than burning a lot of power during suspend to idle. Whether
that's switching to suspend to RAM or shutting down is up to whatever
daemon handles power transitions. That doesn't necessarily cover users
that just use "echo |state| > /sys/power/state", but those users
already have spurious wakes, devices that take a long time to suspend
followed by failures, and other problems to handle.

This patch set does nothing if CONFIG_INTEL_PMC_CORE is not set. If
Linux distros don't want this running they can compile without that
config set since this is currently the only user of that. I could also
add another config flag if that's preferred or if anything else starts
using the INTEL_PMC_CORE code.

>
> Alan

Thanks for the reviews.

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[dbasehore .]

On Thu, Jun 2, 2016 at 6:23 AM, One Thousand Gnomes
 wrote:
> On Thu, 2 Jun 2016 11:25:05 +0200
> Peter Zijlstra  wrote:
>
>> On Wed, Jun 01, 2016 at 09:33:29PM -0700, dbaseh...@chromium.org wrote:
>> > +/*
>> > + * Default chosen to have <= 1% power increase while allowing fast 
>> > detection of
>> > + * SLP S0 entry errors. Waking up 10 times a second shows ~30% increase in
>> > + * system power on Skylake Y. Waking up once every 10 seconds is
>> > + * indistinguishable from not waking up at all (as ~0.3% power increase 
>> > would
>> > + * be). Any reasonable power increases above this will not be visible to 
>> > the
>> > + * user.
>> > + */
>> > +#define DEFAULT_SLP_S0_SECONDS 10
>>
>> So I don't think anybody waits for 10 seconds to see if suspend worked.
>> After 10 seconds its in the bag and I'm out the door.
>>
>> Then what?
>>
>>
>> Why can't you fire a single timer after 0.5 seconds to see if you hit
>> C10 and leave it at that? What's the point any further wakeup, if you
>> know you hit C10, you're good continue on.

That will take care of most of the problems I have seen, but that
doesn't handle everything. Say your audio codec is misconfigured and
causes an interrupt storm when you plug in headphones. The irq handler
won't run, but it could still wake up the system repeatedly and
prevent entry into S0ix.

If this fails, it's not expected that the user catch and handle it,
unless he/she uses "echo freeze > /sys/power/state" to suspend to
idle. It's intended that whatever daemon in user space handles power
state transitions will catch the error and either retry, suspend to
RAM, or shut down the system.

What could happen is we could wake up after 1 second the first time,
then wake up at a slp_s0_seconds after that. This will allow us to
fail faster, still catch issues that happen later, and increase
DEFAULT_SLP_S0_SECONDS to something longer.

>
> There are plenty of Skylake configurations where at the moment you won't
> get s0ix entry because the ISH driver is not yet merged. Spamming those
> users with useless messages is not helpful. Likewise on systems with
> modular kernels your warning may spuriously trigger during boot until the
> ISH, i915 and audio modules and firmware have loaded and are active. I
> know Chrome doesn't like modules but the rest of us do !
>
> I'm also a bit at a loss to understand why anyone needs this except
> validation engineers for Chrome products and kernel hackers doing
> debug. It seems a bit odd to burden the entire world with a pile of
> checks they can't use that cost even 0.3% of power (that's 15 minutes on
> an 8 hour battery multiplied by every Skylake user!).

15 minutes is 4% of 8 hours, but let's take a system that has 8 hours
of battery life for use and 10 days of suspend to idle. 0.3% of 10
days is < 1 hour. That's only for suspend time, though. A user could
lose 1.5 minutes of use, but that's only if the user left his or her
machine suspended for 10 days. I'll probably add the single early wake
that I mentioned before and change this to 100 seconds. At that point,
we're looking at 0.03% power increase, which is < 9 seconds of lost
use for 10 days of suspend to idle.

>
> Having to have debugfs present to turn it off, but not to use it is also
> a bit weird...

I could look into putting this into the cpuidle sysfs.

>
> IMHO this should be one of the hacking/kernel debug options and not even
> compiled into normal kernels.

This patch isn't only about finding the bugs, but doing something more
graceful than burning a lot of power during suspend to idle. Whether
that's switching to suspend to RAM or shutting down is up to whatever
daemon handles power transitions. That doesn't necessarily cover users
that just use "echo |state| > /sys/power/state", but those users
already have spurious wakes, devices that take a long time to suspend
followed by failures, and other problems to handle.

This patch set does nothing if CONFIG_INTEL_PMC_CORE is not set. If
Linux distros don't want this running they can compile without that
config set since this is currently the only user of that. I could also
add another config flag if that's preferred or if anything else starts
using the INTEL_PMC_CORE code.

>
> Alan

Thanks for the reviews.

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[One Thousand Gnomes]

On Thu, 2 Jun 2016 11:25:05 +0200
Peter Zijlstra  wrote:

> On Wed, Jun 01, 2016 at 09:33:29PM -0700, dbaseh...@chromium.org wrote:
> > +/*
> > + * Default chosen to have <= 1% power increase while allowing fast 
> > detection of
> > + * SLP S0 entry errors. Waking up 10 times a second shows ~30% increase in
> > + * system power on Skylake Y. Waking up once every 10 seconds is
> > + * indistinguishable from not waking up at all (as ~0.3% power increase 
> > would
> > + * be). Any reasonable power increases above this will not be visible to 
> > the
> > + * user.
> > + */
> > +#define DEFAULT_SLP_S0_SECONDS 10  
> 
> So I don't think anybody waits for 10 seconds to see if suspend worked.
> After 10 seconds its in the bag and I'm out the door.
> 
> Then what?
> 
> 
> Why can't you fire a single timer after 0.5 seconds to see if you hit
> C10 and leave it at that? What's the point any further wakeup, if you
> know you hit C10, you're good continue on.

There are plenty of Skylake configurations where at the moment you won't
get s0ix entry because the ISH driver is not yet merged. Spamming those
users with useless messages is not helpful. Likewise on systems with
modular kernels your warning may spuriously trigger during boot until the
ISH, i915 and audio modules and firmware have loaded and are active. I
know Chrome doesn't like modules but the rest of us do !

I'm also a bit at a loss to understand why anyone needs this except
validation engineers for Chrome products and kernel hackers doing
debug. It seems a bit odd to burden the entire world with a pile of
checks they can't use that cost even 0.3% of power (that's 15 minutes on
an 8 hour battery multiplied by every Skylake user!).

Having to have debugfs present to turn it off, but not to use it is also
a bit weird...

IMHO this should be one of the hacking/kernel debug options and not even
compiled into normal kernels.

Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[One Thousand Gnomes]

On Thu, 2 Jun 2016 11:25:05 +0200
Peter Zijlstra  wrote:

> On Wed, Jun 01, 2016 at 09:33:29PM -0700, dbaseh...@chromium.org wrote:
> > +/*
> > + * Default chosen to have <= 1% power increase while allowing fast 
> > detection of
> > + * SLP S0 entry errors. Waking up 10 times a second shows ~30% increase in
> > + * system power on Skylake Y. Waking up once every 10 seconds is
> > + * indistinguishable from not waking up at all (as ~0.3% power increase 
> > would
> > + * be). Any reasonable power increases above this will not be visible to 
> > the
> > + * user.
> > + */
> > +#define DEFAULT_SLP_S0_SECONDS 10  
> 
> So I don't think anybody waits for 10 seconds to see if suspend worked.
> After 10 seconds its in the bag and I'm out the door.
> 
> Then what?
> 
> 
> Why can't you fire a single timer after 0.5 seconds to see if you hit
> C10 and leave it at that? What's the point any further wakeup, if you
> know you hit C10, you're good continue on.

There are plenty of Skylake configurations where at the moment you won't
get s0ix entry because the ISH driver is not yet merged. Spamming those
users with useless messages is not helpful. Likewise on systems with
modular kernels your warning may spuriously trigger during boot until the
ISH, i915 and audio modules and firmware have loaded and are active. I
know Chrome doesn't like modules but the rest of us do !

I'm also a bit at a loss to understand why anyone needs this except
validation engineers for Chrome products and kernel hackers doing
debug. It seems a bit odd to burden the entire world with a pile of
checks they can't use that cost even 0.3% of power (that's 15 minutes on
an 8 hour battery multiplied by every Skylake user!).

Having to have debugfs present to turn it off, but not to use it is also
a bit weird...

IMHO this should be one of the hacking/kernel debug options and not even
compiled into normal kernels.

Alan

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[Peter Zijlstra]

On Wed, Jun 01, 2016 at 09:33:29PM -0700, dbaseh...@chromium.org wrote:
> +/*
> + * Default chosen to have <= 1% power increase while allowing fast detection 
> of
> + * SLP S0 entry errors. Waking up 10 times a second shows ~30% increase in
> + * system power on Skylake Y. Waking up once every 10 seconds is
> + * indistinguishable from not waking up at all (as ~0.3% power increase would
> + * be). Any reasonable power increases above this will not be visible to the
> + * user.
> + */
> +#define DEFAULT_SLP_S0_SECONDS 10

So I don't think anybody waits for 10 seconds to see if suspend worked.
After 10 seconds its in the bag and I'm out the door.

Then what?


Why can't you fire a single timer after 0.5 seconds to see if you hit
C10 and leave it at that? What's the point any further wakeup, if you
know you hit C10, you're good continue on.

Re: [PATCH 5/5] intel_idle: Add S0ix validation

[Peter Zijlstra]

On Wed, Jun 01, 2016 at 09:33:29PM -0700, dbaseh...@chromium.org wrote:
> +/*
> + * Default chosen to have <= 1% power increase while allowing fast detection 
> of
> + * SLP S0 entry errors. Waking up 10 times a second shows ~30% increase in
> + * system power on Skylake Y. Waking up once every 10 seconds is
> + * indistinguishable from not waking up at all (as ~0.3% power increase would
> + * be). Any reasonable power increases above this will not be visible to the
> + * user.
> + */
> +#define DEFAULT_SLP_S0_SECONDS 10

So I don't think anybody waits for 10 seconds to see if suspend worked.
After 10 seconds its in the bag and I'm out the door.

Then what?


Why can't you fire a single timer after 0.5 seconds to see if you hit
C10 and leave it at that? What's the point any further wakeup, if you
know you hit C10, you're good continue on.