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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTikcoWfmL-XfYbFeYdVtU9GC6_LtVSSB2H6GcedA@mail.gmail.com>
Date:	Thu, 12 Aug 2010 14:11:22 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Theodore Tso <tytso@....edu>
Cc:	paulmck@...ux.vnet.ibm.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	david@...g.hm, Brian Swetland <swetland@...gle.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, 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

On Thu, Aug 12, 2010 at 1:47 PM, Theodore Tso <tytso@....edu> wrote:
> One thing I'm not clear on --- what's your goal?   Is your goal to keep suspend-blockers out of the kernel?   Is it to try to convince the android team suspend-blockers are a bad idea and to change Android to not use them?  Is it to push some other agenda?  Is it to discourage the Android team from trying to waste more time trying to get suspend-blockers (or equivalent functionality) from being added into the kernel?

My goal is to shine light. I've heard many invalid arguments in favor
of suspend blockers, I want to shut them down.

In my mind it's crystal clear that independently of what opportunistic
suspend is supposed to be fixing, the fact of the matter is that it's
not a silver bullet as it's claimed to be.

So far, nobody has refuted these:
 1) opportunistic suspend needs a good behaved user-space to work properly
 2) if suspend blockers are enabled in a system, *all* user-space must
implement them to work correctly
 3) implementing suspend blockers in user-space is not a straight-forward task
 4) there's a point where sleeping (not doing work) has diminished returns

So, as the length of this thread has shown, the benefits of
opportunistic suspend are *dubious* at best, and more likely not worth
the changes needed in user-space which eventually will get pretty
close to what suspend blockers can achieve even in ideal circumstances
by just doing dynamic PM.

-- 
Felipe Contreras
--
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/