Message-Id: <201005290011.32543.rjw@sisk.pl>
Date:	Sat, 29 May 2010 00:11:32 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Peter Zijlstra <peterz@...radead.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Paul@...p1.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Friday 28 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 17:45 -0700, Arve Hjønnevåg wrote:
> > What happens if the user presses the button right before you set QoS
> > of 'user apps' to  QS_NONE?
> > To me it looks like this solution would result in this sequence which
> > may ignore the button press:
> >         Button pushed
> >         Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
> >         Set QoS of 'user apps' to QS_NONE 
> 
> I don't think we should change app QoS parameters, but change service
> provider parameters.
> 
> For instance, suppose the filesystem-IO QoS has 3 levels: 
>   High, Normal and Idle.
> 
> Then if we assign Idle to updatedb, we'll service it as long as the
> filesystem-server QoS has a higher level (High and Normal). When we
> change the filesystem-serves' QoS to idle, it finds there is nothing to
> keep it servicing stuff and it'll block pending requests, updatedb stops
> being runnable and we're good.

Yeah, that's what I was thinking.  It would be nice to have a mechanism that
would prevent tasks from being runnable in specific conditions (not necessarily
related to power management even).

Having reconsidered the suspend blockers idea I came to the conclusion that
in fact it was a workaround for three different problems.

The first one was that we couldn't power manage I/O devices at run time and
the only way to put them into low-power states was to carry out full system
suspend.  That's changed with the introduction of the runtime PM framework,
but the situation is still not ideal, because in general there's no connection
between the idle infrastructure and runtime PM.

This IMO is the second problem worked around by suspend blockers.
Namely, it generally would be nice to suspend I/O devices when CPUs are idle
for a sufficiently long time.  For this to work, there should be a way to
register a device with the idle framework so that it can tell the device's
driver to suspend the device when it makes sense.  Something like
<vague idea>idle_register_device(dev, t), where t means "suspend that
device after all CPUs have been idle for time t", so basically the idle
framework will only need to run pm_schedule_suspend(dev, t) for that device
right before idling the last CPU</vague idea>.

The third problem is exactly that on Android system there are (or at least
there may be) tasks that in specific situations should not be regarded as
runnable at all and currently there's no way to ensure they won't run other
than going to a full suspend.

If we could address these issues somehow, I think suspend blockers would not be
necessary for maximizing battery life (well, there are some technical details
like automatic going to full suspend when the CPUs and I/O have  been idle for
sufficiently long etc., but they all seem to be tractable).

[And there's a problem of periodic timers that trigger too often, but I think
that's just a general issue that need to be fixed anyway.]

Thanks,
Rafael
--
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