Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Paul E. McKenney on 4 Aug 2010 12:40 On Tue, Aug 03, 2010 at 06:34:47PM -0700, Arjan van de Ven wrote: > On Mon, 2 Aug 2010 21:56:10 -0700 > Arve Hj�nnev�g <arve(a)android.com> wrote: > > > > non-obvious dependencies. > > > > > > > The dependencies is what made this solution uninteresting to us. For > > instance, we currently use cgroup scheduling to reduce the impact of > > some background tasks, but we occasionally saw a watchdog restart of > > the system process were critical services were waiting on a kernel > > mutex owned by a background task for more than 20 seconds. If we froze > > a cgroup instead, we would not hit this particular problem since tasks > > cannot be frozen while executing kernel code the same way they can be > > preempted, but nothing prevents a task from being frozen while holding > > a user-space resource. > > one of the solutions we're looking at to solve this is to unfreeze the > cgroup on a regular basis (say, every 15 to 30 seconds) briefly to avoid > this kind of deadlock... Cute!!! ;-) If this doesn't work for the Android folks for whatever reason, another approach would be to do the freeze in user code, which could track whether any user-level resources (pthread mutexes, SysV semas, whatever) where held, and do the freeze on a thread-by-thread basis within each "victim" application as the threads reach safe points. I must of course defer to the Android folks as to whether or not this would actually work for Android. But if your approach works for them, why worry? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 4 Aug 2010 12:40 On Wed, Aug 04, 2010 at 09:32:16AM -0700, Paul E. McKenney wrote: > If this doesn't work for the Android folks for whatever reason, another > approach would be to do the freeze in user code, which could track > whether any user-level resources (pthread mutexes, SysV semas, whatever) > where held, and do the freeze on a thread-by-thread basis within each > "victim" application as the threads reach safe points. The main problem I see with the cgroups solution is that it doesn't seem to do anything to handle avoiding loss of wakeup events. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: david on 4 Aug 2010 14:40 On Wed, 4 Aug 2010, Matthew Garrett wrote: > On Wed, Aug 04, 2010 at 09:32:16AM -0700, Paul E. McKenney wrote: > >> If this doesn't work for the Android folks for whatever reason, another >> approach would be to do the freeze in user code, which could track >> whether any user-level resources (pthread mutexes, SysV semas, whatever) >> where held, and do the freeze on a thread-by-thread basis within each >> "victim" application as the threads reach safe points. > > The main problem I see with the cgroups solution is that it doesn't seem > to do anything to handle avoiding loss of wakeup events. there are two cgroup solutions in discussion at this point. weeks ago there was the suggestion to put non-privilaged tasks in a cgroup so that they could be frozen as a group. I thought the problem there was that there can be user-space dpendancies that would prevent privilaged tasks from working. a couple days ago I made the suggestion to put non-privilaged tasks in a cgroup so that the idle/suspend decision code could ignore acitivity caused by this cgroup. in the second version wakeup events would be 'activity' that would be counted and therefor the system would not be idle. As for the race with suspending and new things happening, wouldn't that be handled the same way that it is in a normal linux box? David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 4 Aug 2010 14:40 On Tue, Aug 03, 2010 at 08:57:58PM -0700, Arjan van de Ven wrote: > On Tue, 3 Aug 2010 17:10:15 -0700 > "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > > > > OK, I'll bite... > > > > >From an Android perspective, the differences are as follows: > > > > 1. Deep idle states are entered only if there are no runnable > > tasks. In contrast, opportunistic suspend can happen even when there > > are tasks that are ready, willing, and able to run. > > for "system suspend", this is an absolutely valid statement. > for "use suspend as idle state", it's not so clearly valid. > (but this is sort of a separate problem, basically the "when do we > freeze the tasks that we don't like for power reasons" problem, > which in first order is independent on what kind of idle power state > you pick, and discussed extensively elsewhere in this thread) From what I can see, the Android folks are are using "suspend" in the "system suspend" sense. I agree that the proposals for freezing subsets of the tasks in the system are independent of whether idle or suspend is being used. Instead, such freezing depends on (for example) whether or not the display is active. That said, freezing subsets of tasks is a nice-to-have rather than a hard requirement for Android. Though I suspect that the appearance of a reliable way of freezing subsets of tasks just might promote this to a hard requirement. ;-) > > 2. There can be a set of input events that do not bring the > > system out of suspend, but which would bring the system out of a deep > > idle state. For example, I believe that it was stated that > > one of the Android-based smartphones ignores touchscreen input while > > suspended, but pays attention to it while in deep idle states. > > I would argue that this is both a hardware specific issue, but also a > policy issue. From the user point of view, screen off with idle and > screen off with suspend aren't all that different (if my phone would > decide to idle rather than suspend because some app blocks suspend... I > wouldn't expect a difference in behavior when I touch the screen). > "Screen off -> don't honor touch after a bit" is almost an independent, > but very real, policy problem (and a forced one in suspend, I'll grant > you that). I could even argue that the policy decision "we don't care > about the touch screen input" is a pre-condition for entering suspend > (or in android speak, caring for touch screen input/having the touch > screen path active would be a suspend blocker) I agree that the subset of input events that do not bring the system out of suspend would be governed both by hardware capabilities and by policy. > > 3. The system comes out of a deep idle state when a timer > > expires. In contrast, timers cannot expire while the > > system is suspended. (This one is debatable: some people > > argue that timers are subject to jitter, and the suspend > > case for timers is the same as that for deep idle states, > > but with unbounded timer jitter. Others disagree. The > > resulting discussions have produced much heat, but little > > light. Such is life.) > > I'll debate it even harder in that it's platform specific whether > timers can get the system out of suspend or not. Clearly on the Android > platform in question that's not the case, but for some of the Intel > phone silicon for example, timers CAN be wake sources to get you out of > suspend just fine. It just depend on which exact hw you talk about. > Generally, even if the fast timers aren't wake up sources, there'll be > some sort of alarm thing that you can pre-wake.. but yes you are right > in saying that's rather lame. > Either way, it's not a general property of suspend, but a property of > suspend on the specific platform in question. Good point, I do need to emphasize the fact that whether or not timers pull the system out of suspend also depends both on hardware and on policy. So I will change my statement to say something like "The system comes out of a deep idle state when a timer expires. In contrast, timers do not necessarily expire while the system is suspended, depending on both hardware support and platform/application policy." Thanx, Paul > > > -- > Arjan van de Ven Intel Open Source Technology Centre > For development, discussion and tips for power savings, > visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 4 Aug 2010 14:50
On Tue, Aug 03, 2010 at 10:22:55PM -0700, Arve Hj�nnev�g wrote: > On Tue, Aug 3, 2010 at 8:57 PM, Arjan van de Ven <arjan(a)infradead.org> wrote: > > On Tue, 3 Aug 2010 17:10:15 -0700 > > "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > >> > >> OK, I'll bite... > >> > >> >From an Android perspective, the differences are as follows: > >> > >> 1. � �Deep idle states are entered only if there are no runnable > >> tasks. In contrast, opportunistic suspend can happen even when there > >> � � � are tasks that are ready, willing, and able to run. > > > > for "system suspend", this is an absolutely valid statement. > > for "use suspend as idle state", it's not so clearly valid. > > (but this is sort of a separate problem, basically the "when do we > > freeze the tasks that we don't like for power reasons" problem, > > which in first order is independent on what kind of idle power state > > you pick, and discussed extensively elsewhere in this thread) > > > >> > >> 2. � �There can be a set of input events that do not bring the > >> system out of suspend, but which would bring the system out of a deep > >> � � � idle state. �For example, I believe that it was stated that > >> one of the Android-based smartphones ignores touchscreen input while > >> � � � suspended, but pays attention to it while in deep idle states. > > > > I would argue that this is both a hardware specific issue, but also a > > policy issue. From the user point of view, screen off with idle and > > screen off with suspend aren't all that different (if my phone would > > decide to idle rather than suspend because some app blocks suspend... I > > wouldn't expect a difference in behavior when I touch the screen). > > "Screen off -> don't honor touch after a bit" is almost an independent, > > but very real, policy problem (and a forced one in suspend, I'll grant > > you that). I could even argue that the policy decision "we don't care > > about the touch screen input" is a pre-condition for entering suspend > > (or in android speak, caring for touch screen input/having the touch > > screen path active would be a suspend blocker) > > > >> > >> 3. � �The system comes out of a deep idle state when a timer > >> � � � expires. �In contrast, timers cannot expire while the > >> � � � system is suspended. �(This one is debatable: some people > >> � � � argue that timers are subject to jitter, and the suspend > >> � � � case for timers is the same as that for deep idle states, > >> � � � but with unbounded timer jitter. �Others disagree. �The > >> � � � resulting discussions have produced much heat, but little > >> � � � light. �Such is life.) > > > > I'll debate it even harder in that it's platform specific whether > > timers can get the system out of suspend or not. Clearly on the Android > > platform in question that's not the case, but for some of the Intel > > phone silicon for example, timers CAN be wake sources to get you out of > > suspend just fine. It just depend on which exact hw you talk about. > > Generally, even if the fast timers aren't wake up sources, there'll be > > some sort of alarm thing that you can pre-wake.. but yes you are right > > in saying that's rather lame. > > Either way, it's not a general property of suspend, but a property of > > suspend on the specific platform in question. > > > > I disagree. On the msm platform the low level timer that brings us out > of the low power state is the same for idle and suspend. The > difference is where which kernel api the request comes from. In idle, > the next event on the clockevents device is usually the first event. > In suspend the generic kernel timekeeping code cancels this event and > the rtc wakeup event remains. OK, good point. This choice of kernel APIs governs what I was calling "policy". Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |