Message-ID: <20100804200857.GF24163@linux.vnet.ibm.com>
Date:	Wed, 4 Aug 2010 13:08:57 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	david@...g.hm
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, florian@...kler.org, 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 Wed, Aug 04, 2010 at 12:29:36PM -0700, david@...g.hm wrote:
> On Wed, 4 Aug 2010, Matthew Garrett wrote:
> 
> >On Wed, Aug 04, 2010 at 12:15:59PM -0700, david@...g.hm wrote:
> >>On Wed, 4 Aug 2010, Matthew Garrett wrote:
> >>>No! And that's precisely the issue. Android's existing behaviour could
> >>>be entirely implemented in the form of binary that manually triggers
> >>>suspend when (a) the screen is off and (b) no userspace applications
> >>>have indicated that the system shouldn't sleep, except for the wakeup
> >>>event race. Imagine the following:
> >>>
> >>>1) The policy timeout is about to expire. No applications are holding
> >>>wakelocks. The system will suspend providing nothing takes a wakelock.
> >>>2) A network packet arrives indicating an incoming SIP call
> >>>3) The VOIP application takes a wakelock and prevents the phone from
> >>>suspending while the call is in progress
> >>>
> >>>What stops the system going to sleep between (2) and (3)? cgroups don't,
> >>>because the voip app is an otherwise untrusted application that you've
> >>>just told the scheduler to ignore.
> >>
> >>Even in the current implementation (wakelocks), Since the VOIP
> >>application isn't allowed to take a wakelock, wouldn't the system go to
> >>sleep immediatly anyway, even if the application gets the packet and
> >>starts the call? What would ever raise the wakelock to keep the phone
> >>from sleeping in the middle of the call?
> >
> >There's two parts of that. The first is that the voip application is
> >allowed to take a wakelock - but that doesn't mean that you trust it the
> >rest of the time.
> 
> why would you trust it to take a wakelock, but not trust it the rest
> of the time?
> 
> in my proposal I'm saying that if you would trust the application to
> take a wakelock, you instead trust it to be sane in the rest of it's
> power activity (avoiding polling, etc) and so you consider it for
> sleep decisions.

The word "trust" does not appear to be helping here.  ;-)

The VOIP application acquires a suspend blocker when it needs to prevent
the system from suspending, and releases that suspend blocker when it
can tolerate the system suspending.  It is important to note that while
the VOIP application holds the suspend blocker, the system won't suspend
even if it is completely idle (for example, if the VOIP application uses
blocking system calls, during the time that the VOIP application is
waiting for its next event).

> >The second is that the incoming network packet causes
> >the kernel to take a wakelock that will be released once userspace has
> >processed the network packet. This ensures that at least one wakelock is
> >held for the entire relevant period of time.
> 
> how do you determine that userspace has processed the network packet
> so that the kernel can release the wakelock (or is this one of the
> cases where there is a timer related to the wakelock)

There are two cases:

1.	The application is permitted to acquire suspend blockers.
	In this case, the application would acquire a suspend blocker
	before reading the input.  It would then read the input (at
	which point the kernel releases its suspend blocker), do any
	needed processing, and finally release the suspend blocker.

	So in this case, the system knows that the application is
	done processing the input when that application releases
	its suspend blocker.

2.	The application is prohibited from acquiring suspend blockers.
	In this case, the system might well be suspended before the
	application has a chance to do more than read the input.

	But the application will get a chance to process the input
	when the next input event is directed to it.

> two things here,
> 
> on the dirty networks that I see as common, refusing to sleep if
> network packets are arriving will mean that you never go to sleep.
> 
> secondly, nothing stops the code doing the idle/suspend decision
> from considering network activity. I would be surprised if there
> weren't already options to support this today.

I don't know about the general networking case for Android, but the
example of downloading was discussed some time back.  The application
doing the download acquires a suspend blocker, which it releases once
the download is complete (or once a timeout expires, if I remember
correctly).  In this particular case, the network packets were not
bringing the device out of suspend.

There might well be other cases where networking packets -do- bring
the system out of suspend, but I must leave this to someone who knows
more about Android than do I.

							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