[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: Matthew Garrett on 13 May 2010 16:00 On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote: > 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. Ok. So we stick the untrusted bits of userspace on the critical timer list. Now we get a network packet that generates a wakeup event and gets read by an application. What happens if that application can't fully process the packet in a single timeslice? -- 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: Tony Lindgren on 13 May 2010 16:10 * Matthew Garrett <mjg(a)redhat.com> [100513 12:49]: > On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote: > > > 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. > > Ok. So we stick the untrusted bits of userspace on the critical timer > list. I guess you mean the trusted instead of untrusted apps in the userspace above, the ones that are critical to keep running. > Now we get a network packet that generates a wakeup event and gets > read by an application. What happens if that application can't fully > process the packet in a single timeslice? 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. 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/
From: Matthew Garrett on 13 May 2010 16:10 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. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. -- 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: Tony Lindgren on 13 May 2010 16:30 * 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. > I think we could implement your suggestion more easily by just giving > untrusted applications an effectively infinite amount of timer slack, > but it still doesn't handle the case where an app behaves excrutiatingly > badly. Hmm, if you use timer slack then you still need to search through the whole timer list instead of a smaller critical timer list. Both ways sound doable though. 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/
From: Matthew Garrett on 13 May 2010 16:40
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. -- 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/ |