linux-kernel - Re: [PATCH v4 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

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: <CAJZ5v0gbkQmgGuVBxficJjVrOudRTgKKFFp6tFRCG-Byud8Ozg@mail.gmail.com>
Date:	Wed, 11 May 2016 22:45:56 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Sudeep Holla <sudeep.holla@....com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Al Stone <al.stone@...aro.org>,
	Prashanth Prakash <pprakash@...eaurora.org>,
	Ashwin Chaugule <ashwin.chaugule@...aro.org>
Subject: Re: [PATCH v4 2/5] ACPI / processor_idle: Add support for Low Power
 Idle(LPI) states

On Wed, May 11, 2016 at 5:06 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>
>
> On 11/05/16 01:03, Rafael J. Wysocki wrote:
>>
>> On Tuesday, April 19, 2016 01:30:10 PM Sudeep Holla wrote:
>>>

[cut]

>>
>> My main concern about the flattening of _LPI is that at one point we'll
>> probably decide to unflatten it and that will change the behavior for
>> current users.  There needs to be a plan for that IMO.
>>
>
> Are you referring the OS co-ordinated mode ? If yes, I agree. If not,
> can you explain why would we not flatten the LPI states ?

If the platform doesn't autopromote core-level states into
package-level states, then having access to unflattened hierarchy may
be useful.  In some cases the exit latency of core states may be
acceptable, while the exit latency of package states may not be, for
example.

Also the scheduler may want to know which cores are in one package
(from the idle states perspective) at one point.

[cut]

>>> +
>>> +       for (i = 0; i < fl_scnt && i < CPUIDLE_STATE_MAX; i++) {
>>> +               lpi = &pr->power.lpi_states[i];
>>> +
>>> +               state = &drv->states[i];
>>> +               snprintf(state->name, CPUIDLE_NAME_LEN, "LPI-%d", i);
>>> +               strlcpy(state->desc, lpi->desc, CPUIDLE_DESC_LEN);
>>> +               state->exit_latency = lpi->wake_latency;
>>> +               state->target_residency = lpi->min_residency;
>>> +               if (lpi->arch_flags)
>>> +                       state->flags |= CPUIDLE_FLAG_TIMER_STOP;
>>> +               state->enter = acpi_idle_lpi_enter;
>>
>>
>> No ->enter_freeze ?
>>
>
> I don't have a system to test this. Also IIUC the cpuidle does support
> suspend-to-idle even when ->enter_freeze is not implemented right.
> Can we add it later once I find a way to test. Correctly no wakeup on my
> test platform :(

Fair enough.