linux-kernel - Re: [RFC][PATCH 2/2] PM / Domains: Add preliminary cpuidle support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201205122133.58164.rjw@sisk.pl>
Date:	Sat, 12 May 2012 21:33:57 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Shilimkar, Santosh" <santosh.shilimkar@...com>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, Len Brown <lenb@...nel.org>,
	Colin Cross <ccross@...roid.com>,
	Kevin Hilman <khilman@...com>,
	Magnus Damm <magnus.damm@...il.com>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [RFC][PATCH 2/2] PM / Domains: Add preliminary cpuidle support

On Saturday, May 12, 2012, Shilimkar, Santosh wrote:
> On Sat, May 12, 2012 at 12:29 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> > On Friday, May 11, 2012, Santosh Shilimkar wrote:
> >> On Friday 11 May 2012 12:11 AM, Rafael J. Wysocki wrote:
> >> > On Thursday, May 10, 2012, Santosh Shilimkar wrote:
[...]
> Your case is bit special because CPU is also part of the same power
> domain as IO's. Since CPU is part of the root power domain along
> with peripherals, you want CPU to be the device to cut the power in
> the end(idle) and all the notifiers prepares the IO's for the 'cut
> power' which CPU can do in the cpuidle.

No, no notifiers, please, they are clearly suboptimal.

> And then on the reverse chain, notifier will help devices to restore
> the context so that can resume without any issues.

The idea here is to avoid using notifiers.

> Well if CPU is added as one more device along with other
> peripherals, you can still make it work at power domain framework
> level.

What exactly do you mean by "power domain framework level"?  My patch
is at the power domain framework level as far as I can say.

> This can be debated further but I think, we need an agreement
> on CPUIDLE exclusivity.

What do you mean by cpuidle exclusivity?  And what agreement?

> Based on your hardware, say the USB is doing a huge DMA transfer
> and CPU is not doing anything so it will hit idle thread and can idle.

Sure, it will.

> At least your CPU sub-domain can idle because it is quite independent
> even if you can't cut the power for whole domain.

That's correct.  The CPU sub-domain is beyond the scope of my patch.

> Even with your patchset its not possible to cut the power because one of the
> device in the domain is busy. There can be scenario, where say
> SPI is not used for thousands of CPU idle entry/exit so there
> is no need to worry about its context save/restore for every
> idle entry/exit.

The CPU idle state I'm referring to is not the only CPU idle state.
It is an extra state allowing the CPU to go to even deeper idle that usually
if all of the devices in its domain happen to be idle.

Quite obviously there are other idle states along this one that will be used
if this extra state is not enabled.

> The way I am looking at your issue is, every device in a power domain
> including CPU will decrement the powerdomain usecount.

The CPU will not do that, only devices.

> This can be handled through runtime PM.

But this patchset is a part of runtime PM!  What exactly do you mean?

> When they idle, they can save the context
> and the context can be restored only when next time they needs to be
> used. CPU can also decrements the usecount in the idle entry and then check
> whether the usecound of the common PD is zero.

This is not how it is supposed to work.

It doesn't make sense for cpuidle to even try to use the "domain" state if
it is known that some I/O devices in the domain aren't idle.  That's why
that state is disabled in my code whenever one (the first) of the I/O devices
is resumed.  It is then enabled when the last I/O device in the domain goes
idle (the states of all devices are saved at this point, to allow cpuidle to
use the "domain" state without worrying of the devices).

I'll post a new version of the $subject patch shortly, because I found that
the previous one wasn't correct.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/