[PATCH 1/8] PM: Add suspend block api.
in [Kernel]
|
Prev: [PATCH 7/8] Input: Block suspend while event queue is not empty.
Next: [PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.
From: Arve Hjønnevåg on 7 May 2010 17:40 On Fri, May 7, 2010 at 2:30 PM, Daniel Walker <dwalker(a)fifo99.com> wrote: > On Fri, 2010-05-07 at 22:03 +0100, Matthew Garrett wrote: > >> Here's a different example. A process is waiting for a keypress, but >> because it's badly written it's also drawing to the screen at 60 frames >> per second and preventing the system from every going to idle. How do >> you quiesce the system while still ensuring that the keypress will be >> delivered to the application? > > To me it's somewhat of a negative for suspend blockers. Since to solve > the problem you give above you would have to use a suspend blocker in an > asynchronous way (locked in an interrupt, released in a thread too) > assuming I understand your example. I've had my share of semaphore > nightmares, and I'm not too excited to see a protection scheme (i.e. a > lock) which allows asynchronous usage like suspend blockers. > Why do you think this? The example in the documentation describe how we handle key events. -- 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/
From: Matthew Garrett on 7 May 2010 17:50 On Fri, May 07, 2010 at 02:25:56PM -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100507 13:58]: > > Here's a different example. A process is waiting for a keypress, but > > because it's badly written it's also drawing to the screen at 60 frames > > per second and preventing the system from every going to idle. How do > > you quiesce the system while still ensuring that the keypress will be > > delivered to the application? > > I guess it depends. If it's a game and I'm waiting to hit the fire > button, then I don't want the system to suspend! > > It's starting to sound like you're really using suspend blocks > to "certify" that the app is safe to keep running. > > Maybe it could be done with some kind of process flag instead that > would tell "this process is safe to keep running from timer point of view" > and if that flag is not set, then assume it's OK to stop the process > at any point? How do you know to wake the process up in response to the keypress? -- 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 7 May 2010 17:50 * Matthew Garrett <mjg(a)redhat.com> [100507 14:34]: > On Fri, May 07, 2010 at 02:25:56PM -0700, Tony Lindgren wrote: > > * Matthew Garrett <mjg(a)redhat.com> [100507 13:58]: > > > Here's a different example. A process is waiting for a keypress, but > > > because it's badly written it's also drawing to the screen at 60 frames > > > per second and preventing the system from every going to idle. How do > > > you quiesce the system while still ensuring that the keypress will be > > > delivered to the application? > > > > I guess it depends. If it's a game and I'm waiting to hit the fire > > button, then I don't want the system to suspend! > > > > It's starting to sound like you're really using suspend blocks > > to "certify" that the app is safe to keep running. > > > > Maybe it could be done with some kind of process flag instead that > > would tell "this process is safe to keep running from timer point of view" > > and if that flag is not set, then assume it's OK to stop the process > > at any point? > > How do you know to wake the process up in response to the keypress? Does it matter for processes that are not "certified"? Maybe you could assume that you can keep it stopped until the screen is on again, or some other 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: Matthew Garrett on 7 May 2010 17:50 On Fri, May 07, 2010 at 02:42:11PM -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100507 14:34]: > > How do you know to wake the process up in response to the keypress? > > Does it matter for processes that are not "certified"? Maybe you > could assume that you can keep it stopped until the screen is on > again, or some other policy. Yes, it matters. You don't necessarily know whether to turn the screen on until the app has had an opportunity to process the event. This is exactly the kind of use case that suspend blocks are intended to allow, so alternatives that don't permit that kind of use case aren't really adequate alternatives. -- 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: Daniel Walker on 7 May 2010 17:50
On Fri, 2010-05-07 at 14:35 -0700, Arve Hjønnevåg wrote: > On Fri, May 7, 2010 at 2:30 PM, Daniel Walker <dwalker(a)fifo99.com> wrote: > > On Fri, 2010-05-07 at 22:03 +0100, Matthew Garrett wrote: > > > >> Here's a different example. A process is waiting for a keypress, but > >> because it's badly written it's also drawing to the screen at 60 frames > >> per second and preventing the system from every going to idle. How do > >> you quiesce the system while still ensuring that the keypress will be > >> delivered to the application? > > > > To me it's somewhat of a negative for suspend blockers. Since to solve > > the problem you give above you would have to use a suspend blocker in an > > asynchronous way (locked in an interrupt, released in a thread too) > > assuming I understand your example. I've had my share of semaphore > > nightmares, and I'm not too excited to see a protection scheme (i.e. a > > lock) which allows asynchronous usage like suspend blockers. > > > > Why do you think this? The example in the documentation describe how > we handle key events. +- The Keypad driver gets an interrupt. It then calls suspend_block on the + keypad-scan suspend_blocker and starts scanning the keypad matrix. +- The keypad-scan code detects a key change and reports it to the input-event + driver. +- The input-event driver sees the key change, enqueues an event, and calls + suspend_block on the input-event-queue suspend_blocker. +- The keypad-scan code detects that no keys are held and calls suspend_unblock + on the keypad-scan suspend_blocker. +- The user-space input-event thread returns from select/poll, calls + suspend_block on the process-input-events suspend_blocker and then calls read + on the input-event device. +- The input-event driver dequeues the key-event and, since the queue is now + empty, it calls suspend_unblock on the input-event-queue suspend_blocker. +- The user-space input-event thread returns from read. If it determines that + the key should leave the screen off, it calls suspend_unblock on the + process_input_events suspend_blocker and then calls select or poll. The + system will automatically suspend again, since now no suspend blockers are + active. This? Isn't this asynchronous on the input-event-queue since it's taken in the interrupt , and release in the userspace thread? Daniel -- 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/ |