[PATCH 0/8] Suspend block api (version 6)
in [Kernel]
|
Prev: [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending
Next: [PATCH 7/8] Input: Block suspend while event queue is not empty.
From: Rafael J. Wysocki on 13 May 2010 18:10 On Thursday 13 May 2010, Tony Lindgren wrote: > * Alan Stern <stern(a)rowland.harvard.edu> [100513 14:36]: > > On Thu, 13 May 2010, Tony Lindgren wrote: > > > > > Well this is an interesting problem, and once solved will be handy > > > for all kind of things. My worry is that if it's integrated in it's > > > current form it will be totally out of control all over the place :( > > > > > > Still hoping we can come up with some clean way that avoid the patching > > > all over the place part.. How about the following, can you please check > > > if it would help with your example of guaranteed handling of event: > > > > > > 1. In the kernel, we add one more timer queue for critical timers. > > > The current timer queue(s) stay as it is. > > > > > > 2. We allow selecting the timer based on some flag, the default > > > behaviour being the current default timer queue. > > > > > > 3. Then we add next_timer_interupt_critical() to only query the > > > critical timers along the lines of the current next_timer_interrupt(). > > > > > > 4. We implement a custom pm_idle that suspends the system based on > > > some logic and checking if next_timer_interrupt_critical() is > > > empty. If the next_timer_interrupt_critical() does not return > > > anything, we assume it's OK to suspend the system. > > > > > > Now to me it sounds if your the input layer and userspace handle > > > both grab the timers with the critical flags, it should be guaranteed > > > that the events get handled before the system is suspended. > > > > Why do you want this to be tied to timers? Many of the events in > > question are asynchronous with no specific timing relations. > > To me it seems that the non-timer related events can be dealt > with toggling the opportunistic suspend idle flag in sysfs. > That should depend on the device and use specific policy. OK, that's all hand waving. Do you have any patches, please? Rafael -- 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: Alan Stern on 13 May 2010 18:10 On Thu, 13 May 2010, Tony Lindgren wrote: > > > And that's why > > > it should be handled by runtime power management instead. > > > > Runtime PM is not capable of freezing userspace and shutting down CPUs. > > More or less by definition -- if it could then it wouldn't be "runtime" > > any more, since the processor wouldn't be running. > > Not true. We are already powering off CPUs and rebooting them for > at least omaps in every idle loop using cpuidle. The memory stays on. Okay, that's a valid point. But is that approach usable in general (i.e., on non-OMAP systems)? How do you handle situations where the CPU is currently idle but an event (such as I/O completion) is expected to occur in the near future? You don't want to power-off and reboot then, do you? Alan Stern -- 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: Rafael J. Wysocki on 13 May 2010 18:30 On Friday 14 May 2010, Tony Lindgren wrote: > * Alan Stern <stern(a)rowland.harvard.edu> [100513 14:56]: > > On Thu, 13 May 2010, Tony Lindgren wrote: > > > > > > > And that's why > > > > > it should be handled by runtime power management instead. > > > > > > > > Runtime PM is not capable of freezing userspace and shutting down CPUs. > > > > More or less by definition -- if it could then it wouldn't be "runtime" > > > > any more, since the processor wouldn't be running. > > > > > > Not true. We are already powering off CPUs and rebooting them for > > > at least omaps in every idle loop using cpuidle. The memory stays on. > > > > Okay, that's a valid point. But is that approach usable in general > > (i.e., on non-OMAP systems)? > > Yes if your system wakes to interrupts at least. If your system does > not wake to timer events, then you'll get missed timers. So it should > work on PC too with CONFIG_NO_HZ and if RTC was used for the timer > wake event. > > > How do you handle situations where the CPU is currently idle but an > > event (such as I/O completion) is expected to occur in the near future? > > You don't want to power-off and reboot then, do you? > > The idle code looks at next_timer_interrupt() value, then if the > next timer event if far enough ahead, the system powers down and > wakes to the timer interrupt. It also wakes to device interrupts. For the record, waking to interrupts doesn't work on quite some systems (like ACPI-based PCs for one example). Rafael -- 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: tytso on 13 May 2010 18:30 On Thu, May 13, 2010 at 02:25:56PM -0700, Tony Lindgren wrote: > > I agree and I don't understand the problem that people have with the > > opportunistic suspend feature. > > It seems to be picking quite a few comments for one. It's picking up a lot of comments because *someone* seems to be trying to use a "last post wins" style of argumentation. One of the things that is hard for people who aren't regular denizens of LKML is to understand whose comments can be ignored..... Seriously, you are posting a lot, but it's not clear you're making any clear sense... - Ted -- 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: Arve Hjønnevåg on 13 May 2010 18:30
On Thu, May 13, 2010 at 12:42 PM, Tony Lindgren <tony(a)atomide.com> wrote: > * Matthew Garrett <mjg(a)redhat.com> [100513 12:20]: >> On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote: >> > The suspend blocks seems like a hack to spam filter good and bad >> > apps from timer usage point of view. Applications are categorized >> > as good or bad depending if they grab a susped blocker or not. >> > >> > I believe categorizing the apps should be instead done with some >> > timer flags or cgroups instead. >> >> I agree, but we have no mechanism for implementing that in a race-free >> way. We don't even have a realistical proposal for what that mechanism >> would look like. Should we refuse bread today for the promise of cake >> tomorrow? > > Well this is an interesting problem, and once solved will be handy > for all kind of things. My worry is that if it's integrated in it's > current form it will be totally out of control all over the place :( > > Still hoping we can come up with some clean way that avoid the patching > all over the place part.. How about the following, can you please check > if it would help with your example of guaranteed handling of event: > > 1. In the kernel, we add one more timer queue for critical timers. > � The current timer queue(s) stay as it is. > > 2. We allow selecting the timer based on some flag, the default > � behaviour being the current default timer queue. > > 3. Then we add next_timer_interupt_critical() to only query the > � critical timers along the lines of the current next_timer_interrupt(). > > 4. We implement a custom pm_idle that suspends the system based on > � some logic and checking if next_timer_interrupt_critical() is > � empty. If the next_timer_interrupt_critical() does not return > � anything, we assume it's OK to suspend the system. > I think trying to solve this at the timer level requires more patching than using suspend blockers. With suspend blocker you block suspend until some work has finished, or an event has been consumed. You can safely use any existing synchronous api. > Now to me it sounds if your the input layer and userspace handle > both grab the timers with the critical flags, it should be guaranteed > that the events get handled before the system is suspended. > There are no timers used in this path. However any critical section used from this path could cause the system to enter idle. Instead of blocking suspend while there are unprocessed input event you now have to make sure all code that can block any of the threads involved in processing those event don't wait on a non critical timer. -- Arve Hj�nnev�g -- 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/ |