linux-kernel - Re: Attempted summary of suspend-blockers LKML thread, take three

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 10 Aug 2010 15:40:26 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	paulmck@...ux.vnet.ibm.com, "Ted Ts'o" <tytso@....edu>,
	Felipe Contreras <felipe.contreras@...il.com>, david@...g.hm,
	Brian Swetland <swetland@...gle.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, pavel@....cz, florian@...kler.org, rjw@...k.pl,
	stern@...land.harvard.edu, peterz@...radead.org,
	tglx@...utronix.de, menage@...gle.com, david-b@...bell.net,
	James.Bottomley@...e.de, arjan@...radead.org, swmike@....pp.se,
	galibert@...ox.com, dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take three

> > Losing data is a design choice ? The application set a timer, the OS
> > shouldn't be ignoring it in that situation. It might want to delay it, it
> > might want to warn the user its hogging things it shouldnt (powertop,
> > battery usage monitors in Android etc)
> 
> So we should remove explicit system suspend from the kernel?

Explicit suspend is user triggered - in the laptop case its a bit
different. I don't btw like the fact that a laptop explicit suspend
doesn't end up as a dbus "save data" and openoffice save (or it didn't
last time I looked which is a while ago).

> There's a clear and absolute difference between system suspend and 
> entering the same hardware state from the idle loop. That difference is 
> that processes aren't scheduled until an explicit wakeup event occurs. 
> Android is entirely capable of entering the same low power state at idle 
> (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but 
> if you have more than 0 scheduling wakeups a second then your power draw 
> is going to be greater. 

And nothing stops you also implementing a 'forced' suspend, although you
can do that nicely by simply stopping the process group that contains the
stuff you don't want to stop suspend and dropping into suspend when you
idle.

> I agree that we should be targetting 0 wakeups per second. I don't agree 
> that it's realistic to insist that a use model that assumes imperfect 
> software is an invalid use model.

No argument.

The question is what applications should be expressing to the kernel
which is not tied to assumptions like 'suspend mode' and which is generic.

We don't have xfs stuff for example splattered all over userspace and in
lots of drivers - we have generic interfaces. That way user community A
doesn't have to care about user community B's choices, and JFFS flash fs
people don't offend big data centre people and vice versa.

Alan
--
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/