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

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: <20100802074429.73a9dfd9@schatten.dmk.lab>
Date:	Mon, 2 Aug 2010 07:44:29 +0200
From:	Florian Mickler <florian@...kler.org>
To:	david@...g.hm
Cc:	Arjan van de Ven <arjan@...radead.org>, paulmck@...ux.vnet.ibm.com,
	"Ted Ts'o" <tytso@....edu>, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, arve@...roid.com,
	mjg59@...f.ucam.org, pavel@....cz, rjw@...k.pl,
	stern@...land.harvard.edu, swetland@...gle.com,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
david@...g.hm wrote:

> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
> 
> > I'm a little worried that this whole "I need to block suspend" is
> > temporary. Yes today there is silicon from ARM and Intel where suspend
> > is a heavy operation, yet at the same time it's not all THAT heavy
> > anymore.... at least on the Intel side it's good enough to use pretty
> > much all the time (when the screen is off for now, but that's a memory
> > controller issue more than anything else). I'm pretty sure the ARM guys
> > will not be far behind.
> 
> remember that this 'block suspend' is really 'block overriding the fact 
> that there are still runable processes and suspending anyway"
> 
> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound 
> as if it blocks any attempt to suspend, and I'm not sure that's what's 
> really intended. Itsounds like the normal syspend process would continue 
> to work, just this 'ignore if these other apps are busy' mode of operation 
> would not work.
> 
> which makes me wonder, would it be possible to tell the normal idle 
> detection mechanism to ignore specific processes when deciding if it 
> should suspend or not? how about only considering processes in one cgroup 
> when deciding to suspend and ignoring all others?
> 
> David Lang

We then get again to the "runnable tasks" problem that was
discussed earlier... the system get's "deadlock-prone" if a subset of
tasks is not run. 
Interprocess dependencies are not so easy to get right in general.

Cheers,
Flo
--
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/