[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: Greg KH on 13 May 2010 17:50 On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: > > > Because someone would have to remove suspend blockers (or rather wakelocks) > > from the drivers, test that they work correctly without suspend blockers and > > submit the modified versions. Going forward, every party responsible for such > > a driver would have to maintain an out-of-tree version with suspend blockers > > (or wakelocks) anyway, so the incentive to do that is zero. > > They should work without wakelock since wakelock are optional .. I mean > there's nothing in suspend blockers I've seen that indicates it's > required for some drivers to work. So it's just a matter of patching out > the wakelocks, with no need to re-test anything. > > You get the driver mainlined, then maintain a small patch to add > wakelocks. Not hard at all , with lots of incentive to do so since you > don't have to maintain such a large block of code out of tree. Sorry, but it doesn't seem to work that way. Look at the large number of out-of-tree android device drivers that remain sitting there because of the lack of this interface being in the kernel. Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. thanks, greg k-h -- 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:00 On Thursday 13 May 2010, Tony Lindgren wrote: > * Rafael J. Wysocki <rjw(a)sisk.pl> [100513 14:16]: > > On Thursday 13 May 2010, Matthew Garrett wrote: > > > On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: > > > > * Matthew Garrett <mjg(a)redhat.com> [100513 13:03]: > > > > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > > > > > > > > > > > The system stays running because there's something to do. The system > > > > > > won't suspend until all the processors hit the kernel idle loop and > > > > > > the next_timer_interrupt_critical() returns nothing. > > > > > > > > > > At which point an application in a busy loop cripples you. > > > > > > > > Maybe you could deal with the misbehaving untrusted apps in the userspace > > > > by sending kill -STOP to them when the screen blanks? Then continue > > > > when some event wakes up the system again. > > > > > > And if that's the application that's listening to the network socket > > > that you want to get a wakeup event from? This problem is hard. I'd love > > > there to be an elegant solution based on using the scheduler, but I > > > really don't know what it is. > > > > 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 solves a practical issue that _at_ _the_ _moment_ cannot be solved > > differently, while there's a growing number of out-of-tree drivers depending > > on this framework. We need those drivers in and because we don't have any > > viable alternative at hand, we have no good reason to reject it. > > Nothing is preventing merging the drivers can be merged without > these calls. And yet, there _is_ a growing nuber of drivers that don't get merge because of that. That's _reality_. Are you going to discuss with facts, or what? 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: Rafael J. Wysocki on 13 May 2010 18:00 On Thursday 13 May 2010, Tony Lindgren wrote: > * Rafael J. Wysocki <rjw(a)sisk.pl> [100513 14:08]: > > On Thursday 13 May 2010, Tony Lindgren wrote: > > > > > > The difference between echo mem > /sys/power/state and suspend blocks > > > is that with suspend blocks the system keeps running. > > > > Care to elaborate? > > The suspend blocks affects the runtime behaviour of the system by > categorizing apps into good and bad apps in a weird way. I don't see this, can you please explain? 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: Tony Lindgren on 13 May 2010 18:00 * 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. Tony -- 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: Tony Lindgren on 13 May 2010 18:10
* 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 drivers to block hitting off-idle custom idle functions can be used. Paul Walmsley and Kevin Hilman have some ideas on having generic latency information available for that. So there are similar issues to opportunistic suspend + suspend blocks that should be sorted out in a generic way. For the drivers to power down, some timeout value seems to work best. Regards, Tony -- 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/ |