Message-ID: <AANLkTimqHZsm2g-yzl_XF0Wmtt9QZ9wfmLKaxJDWc5im@mail.gmail.com>
Date:	Fri, 28 May 2010 14:53:31 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Brian Swetland <swetland@...gle.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Igor Stoppa <igor.stoppa@...ia.com>, tytso@....edu,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Fri, May 28, 2010 at 9:31 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> I think Arve's concern was the representation of the "I care, but only
>> a little" or "just low enough to ensure threads must run" level which
>> is what suspend blockers would map to (low enough to ensure we
>> shouldn't halt the world but not necessarily implying a hard latency
>> constraint beyond that).
>
> That's why I suggested "manyana" (can't get accents for mañana in a
> define) or perhaps "dreckly"[1]. They are both words that mean "at some
> point" but in a very very vague and 'relax it'll happen eventually' sense.
>
> More importantly it's policy. It's a please meet this constraint guide
> to the PM layer - not a you must do as say even if its stupid.

Huh?

>
>> > They fix a general problem in terms of a driver specific item. We end up
>> > making changes around the tree but we make everyone happy not just
>> > Android. Also we are isolating policy properly. The apps and drivers say
>> > "I have these needs", the power manager figures out how to meet them.
>>
>> That makes sense -- and as I've mentioned elsewhere, we're really not
>> super picky about naming -- if it turns out that
>> wakelocks/suspendblockers were shorthand for "request a qos constraint
>> that ensures that threads are running", we'll be able to get things
>> done just as well as we do now.
>
> Cool. I think they are or at least they are close enough that nobody will
> notice the join ;)
>
>> > Where it gets ugly is if you start trying to have drivers giving an app a
>> > guarantee which the app then magically has to know to dispose of.
>>
>> Yeah -- which is something we've avoided in the existing model with
>> overlapping wakelocks during handoff between domains.
>
> I'm not sure avoided is the right description - its there in all its
> identical ugliness in wakelock magic
>
> If you treat QoS guarantees as a wakelock for your purposes (which is
> just fine, drivers and apps give you policy, you use it how you like)
> then you could write the paragraph below substituting the word
> 'guarantee' for 'wakelock' So in that sense the mess is the same because
> in both cases you are trying to suspend active tasks rather than asking
> the task to behave and then taking remedial action with offenders.
>
>> - input service is select()ing on input devices
>> - when select() returns it grabs a wakelock, reads events, passes them
>> on, releases the wakelock
>> - the event subsystem can then safely drop its "should be running
>> threads" constraint as soon as the last event is read because it has
>> no queues for userspace to drain, but the overlapping wakelock
>> prevents the system from immediately snapping back to sleep
>
> The conventional PC model is 'we don't go back into sleep proper fast
> enough for that race to occur'.

This is the same as saying these two threads don't run often enough to
need a mutex around their critical section. Just because you have not
been bitten by the race yet, does not mean it does not exist.

> It's hard to see how you change it. An

If each layer prevents suspend while it knows there are pending events
you don't have a race. Suspend blockers lets you do this.

> app->device "thank you for that event, I enjoyed it very much and have
> finished with it" message moves the underlying event management and QoS
> knowledge into he driver proper but doesn't really change the interface.
>
Yes you can do this, and it it how the android alarm driver works, but
we found the select()/poll(), block suspend, read event, process event
then unblock suspend sequence cleaner (especially for interfaces that
can return more than one event at a time). Kernel suspend blocker lets
you implement the alarm driver model, adding user-space suspend
blockers lets you implement the second.

>> > If you are prepared to exclude untrusted apps from perfectly reliable
>> > event reporting (ie from finger to application action) that doesn't seem
>> > to be a neccessity anyway.
>>
>> Currently in the Android userpace only trusted (system) apps can
>> directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
>> trusted system service (which ensures the app has been granted
>> permission to do this and tracks usage for accountability to
>> user/developer).
>
> Clearly that would continue to work out.
>
> Alan
> [1] Dreckly being used in Cornwall, as one friend put it 'Like manãna but
> without that dreadful sense of urgency'
>
> --
> 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/
>



-- 
Arve Hjønnevåg
--
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