linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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: <AANLkTimE1N76sB6UHm4-YMJ97gQ7-Ztndf97dTLdm5nX@mail.gmail.com>
Date:	Wed, 2 Jun 2010 02:32:57 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Florian Mickler <florian@...kler.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Paul@...p1.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

2010/6/2 Thomas Gleixner <tglx@...utronix.de>:
> On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/2 Thomas Gleixner <tglx@...utronix.de>:
>> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
>> >>
>> >> Because suspend itself causes you to not be idle you cannot abort
>> >> suspend just because you are not idle anymore.
>> >
>> > You still are addicted to the current suspend mechanism. :)
>> >
>>
>> No I want you to stop confusing low power idle modes with suspend. I
>> know how to enter low power modes from idle if that low power mode is
>> not too disruptive.
>
> What prevents us from going into a disruptive mode from idle ? I don't
> see a reason - except crappy ACPI stuff, which I'm happy to ignore.
>

What do you consider disruptive? Disabling active interrupts? Stopping
the monotonic clock?

>> > If I understood you correctly then you can shutdown the CPU in idle
>> > completelty already, but that's not enough due to:
>> >
>> >    1) crappy applications keeping the cpu away from idle
>> >    2) timers firing
>> >
>> > Would solving those two issues be sufficient for you or am I missing
>> > something ?
>>
>> Solving those two is enough for current android phones, but it may not
>> be enough for other android devices.
>
> In which way ? May not be enough is a pretty vague statement.

They may not be based on hardware that can get to the same power mode
from idle as suspend. This could be acpi based hardware, it could be
like the hardware we started with that did not have regular timers
that could run in the low power mode, or devices could loose their
state in the lowest power mode.

>
>> 1 is not solvable (meaning we cannot fix all apps),
>
> We can mitigate it with cgroups and confine crap there, i.e. force
> idle them.
>

I think using suspend is much simpler. It avoids having to worry about
dependencies between processes.

>> and 2 is difficult to fix since the periodic
>> work is useful while the device is actually in use. One possible way
>> to solve 2 is to allow timers on a not-idle clock.
>
> That's what I had in mind.
>
>> Unrelated to Android, I also want to use opportunistic suspend on my
>> desktop.
>
> I expect that intel/amd fixing their stuff is going to happen way
> before we sprinkled suspend blockers over a full featured desktop
> distro.
>

You do not need to sprinkle suspend blocker all over the distro for it
to be useful. You can convert the existing auto-suspend code to use
opportunistic suspend and all apps that don't use suspend blocker will
behave as they do today while allowing apps to use suspend blockers to
keep the system running after the auto-suspend timeout expired.

-- 
Arve Hjønnevåg
--
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/