Messages in this thread | | | Date | Tue, 8 Jun 2010 12:19:54 +0200 | From | Florian Mickler <> | Subject | Re: [linux-pm] suspend blockers & Android integration |
| |
On Mon, 7 Jun 2010 20:05:56 -0700 Arve Hjønnevåg <arve@android.com> wrote: Hi,
> > If you read an event that occurred after you blocked the task > freezing, then tasks will never get frozen again (until more events > occur). I think my original description was less confusing, but it > seems you got completely distracted by my use of block and unblock > suspend when referring to the user space api.
Here is how I understood Alan's approach:
Userspace manager (UM) does:
<...continuation of function A> 5) unblock from reading a wakeup from wakeupevents-fd 6) thaw userspace 7) return </function A>
[userspace sees there is an event; blocks suspend at UM; processes event; consume wakeupevent at UM; unblock suspend at UM;]
Unblocking the last suspend-blocker at the UM starts function A:
<function A> 1) non-blocking read of wakeup-events-fd (refills wakeupevents) 2) if all wakeupevents are consumed: 3a) freeze userspace else 3b) /* wait for userspace to unblock suspend again... this should take care of the races? */ return; 4) blocking read of wakeupevents-fd <...for continuation see above>
You mitigate the race by freezing and unfreezing userspace. If there occur wakeups between 3a) and 4) you will have frozen userspace in vain.
So I think the feasibility of this solution depends on the performance of freezing/thawing userspace. I can't judge that.
Also I _think_ this is racefree as long as you have the UM properly serialized. Or did I overlook something?
Cheers, Flo
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |