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: <20100812174303.GD2524@linux.vnet.ibm.com>
Date:	Thu, 12 Aug 2010 10:43:03 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Theodore Tso <tytso@....edu>, 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 02:11:22PM +0300, Felipe Contreras wrote:
> 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.

The question is not whether suspend blockers are a silver bullet (in my
opinion there are no silver bullets), but rather whether or not suspend
blockers are useful.

> So far, nobody has refuted these:
>  1) opportunistic suspend needs a good behaved user-space to work properly

As does dynamic power management.

>  2) if suspend blockers are enabled in a system, *all* user-space must
> implement them to work correctly

Really?  From what I can see, only PM-driving applications need to use
suspend blockers.

>  3) implementing suspend blockers in user-space is not a straight-forward task

Fortunately, experience thus far has shown that only a small fraction of
applications need to use suspend blockers.  (Or perhaps you are instead
saying that the implementation of the suspend-blocker infrastructure
itself is not straightforward?  It is not clear from your words.)

>  4) there's a point where sleeping (not doing work) has diminished returns

This one I agree with.

> 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.

The length of this thread (and the ones preceding it) is mostly due to
people talking past each other.  For example, the Android folks seem to
believe that it is important that relatively unskilled people be able
to write simple apps, and that the system nevertheless be able to run
these apps in a relatively energy efficient manner.  Your proposals do
not address this issue.  This might be because you are not aware of
this desire, because you are not aware of the computing history that
argues in favor of this requirement, or because you simply don't like
this requirement.  Whatever the reason, until you face this requirement
head on, either addressing it or proving that it need not be addressed,
you will continue to be talking past the Android folks.

							Thanx, Paul
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ