Re: suspend blockers & Android integration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2010/6/6 Rafael J. Wysocki <rjw@xxxxxxx>:
> On Sunday 06 June 2010, Arve Hjønnevåg wrote:
>> 2010/6/5 Rafael J. Wysocki <rjw@xxxxxxx>:
>> > On Saturday 05 June 2010, Arve Hjønnevåg wrote:
>> >> 2010/6/5 Thomas Gleixner <tglx@xxxxxxxxxxxxx>:
>> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
> ...
>> >
>> > Arve, we're still learning you have some more requirements we had no idea
>>
>> What new requirement are you talking about. Did you assume all our
>> user-space ipc calls went though a single process?
>
> No, but I didn't assume that your wakelock-holding processes depend on the
> other processes in a way that might prevent them from acquiring or dropping
> a wakelock.
>

It does not prevent it from acquiring a wakelock (assuming the already
held wakelock does not have a timeout), but it could delay it and
cause an error dialog to pop up stating that the fozen app is
misbehaving.

> ...
>> >> >> Trusted code that calls into untrusted code has to deal with the
>> >> >> untrusted code not responding, but we only want to pop up a message
>> >> >> that the application is not responding if it is misbehaving, not just
>> >> >> because it was frozen though no fault of its own.
>> >
>> > When Android starts opportunistic suspend, all applications are frozen,
>> > "trusted" as well as "untrusted", right?  So, after they are all frozen, none
>> > of them can do anything to prevent suspend from happening, right?
>>
>> Not if you mean when we write to /sys/power/state. Processes are not
>> frozen until the last suspend blocker is released.
>
> That doesn't matter.  In the opportunistic mode you don't need to write into
> /sys/power/state to start suspend, this is done by the kernel automatically as
> soon as the last wakelock has been released (at least this is my assumption
> about how this works).  Now, at this point the processes that don't use
> wakelocks can't really prevent themselves from being frozen and only the
> wakelocks users can do that.  So, if a wakelock user depends on a process
> that doesn't use wakelocks in such a way that (because of that dependence) it
> can't acquire its wakelock while processes are being frozen, things don't work
> as they are supposed to.
>
You seem to forget that we use overlapping wakelocks. A process that
need to acquire a wakelock does so before the driver it talks to
releases its wakelock. At this point no processes are frozen.

>> > Now, in my proposed approach the "untrusted" apps are frozen exactly at the
>> > point Android would start opportunistic suspend and they wouldn't be able
>> > to do anything about that anyway.  So if one of your "trusted" apps depends
>> > on the "untrusted" ones in a way that you describe, you alread have a bug
>> > (the "trusted" app cannot prevent automatic suspend from happening even if it
>> > wants, because it depends on an "untrusted" app that has just been frozen).
>> >
>>
>> I don't think what you said here is correct. If a wakeup event happens
>> all processed are unfrozen since the driver blocks suspend.
>
> This only means that the theoretical failure you gave as an example doesn't
> happen in practice.  No problem, then. :-)
>

If individual processes are frozen, we run into problems that we
cannot run into if we freeze and thaw all processes.

>> The app that reads this event blocks suspend before reading it. If it was
>> busy talking to a less trusted app when the event happened it still works
>> since all apps are running at this point.
>
> And how is this different from an approach with cgroup freezing?  Apps that
> use wakelock within the current framework would use "freeze locks" to prevent
> the "untrusted" part of user space from being frozen or to thaw it.  Where's
> the problem, then?
>

They will not be able to get wakeup events directly from the kernel.
If the kernel does not thaw processes when a wakeup event happens, the
app may never get to the point where it grabs its wakelock.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux