Message-ID: <87y6fgn9y1.fsf@deeprootsystems.com>
Date:	Tue, 18 May 2010 15:04:22 -0700
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Greg KH <gregkh@...e.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Brian Swetland <swetland@...gle.com>,
	Daniel Walker <dwalker@...o99.com>,
	"Theodore Ts'o" <tytso@....edu>, Matthew Garrett <mjg@...hat.com>
Subject: Re: [PATCH 0/8] Suspend block api (version 7)

"Rafael J. Wysocki" <rjw@...k.pl> writes:

> On Tuesday 18 May 2010, Kevin Hilman wrote:
>> Arve Hjønnevåg <arve@...roid.com> writes:
>> 
>> >
>> > PM: Opportunistic suspend support.
>> >
>> > Power management features present in the current mainline kernel are
>> > insufficient to get maximum possible energy savings on some platforms,
>> > such as Android, because low power states can only safely be entered
>> > from idle.  Suspend, in its current form, cannot be used, since wakeup
>> > events that occur right after initiating suspend will not be processed
>> > until another possibly unrelated event wake up the system again.
>> 
>> I think the problems with wakeups in the current suspend path need to
>> be described in more detail.  In particular, why check_wakeup_irqs()
>> is not enough etc.
>
> That one is really easy.: because some (the majority of?) architectures
> don't even implement it.

OK, then this problem will still in traditional suspend even after
this series, so calling it out as a the problem to be solved but not
fixing it doesn't seem right.

This problem needs an independent fix, namely implementing
check_wakeup_irqs().

That being said, what exactly is there for architectures to implement
for check_wakeup_irqs()?  IIUC, this all handled by genirq as long as
deferred disable (now the default) is used?

I suspect the platforms that Android currently cares about already
have this functionality.  At least OMAP does already.

>> > On some systems idle combined with runtime PM can enter the same power
>> > state as suspend, but periodic wakeups increase the average power
>> > consumption. Suspending the system also reduces the harm caused by
>> > apps that never go idle. On other systems suspend can enter a much
>> > lower power state than idle.
>> >
>> > To allow Android and similar platforms to save more energy than they
>> > currently can save using the mainline kernel, we introduce a mechanism
>> > by which the system is automatically suspended (i.e. put into a
>> > system-wide sleep state) whenever it's not doing useful work, called
>> > opportunistic suspend.
>> 
>> A definition of "useful work" here would provide clarity and would
>> also help clarify by what criteria other on-going work is determined
>> to be not useful.
>
> Probably "useful" is not the right word here.  I guess it's more like
> "work that can be deferred without visible impact on functionality".

OK, then a definition of "visible impact on functionality" should be
provided and the critera for determining that.

I know this sounds like splitting hairs, but what I'm getting at is
that this series implements a brand new method for making decisions
about when the system is idle.  That fact should be clearly stated and
the criteria for making this decision should be clearly described.

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