PM: Avoid losing wakeup events during suspend
in [Kernel]
|
Prev: [PATCH] [RFC] kvm: time accelerator/decelerator for kvm guests
Next: wait_for_completion_interruptible does not wait !!
From: Alan Stern on 21 Jun 2010 18:20 On Mon, 21 Jun 2010, Florian Mickler wrote: > > In the end you would want to have communication in both directions: > > suspend blockers _and_ callbacks. Polling is bad if done too often. > > But I think the idea is a good one. > > Actually, I'm not so shure. > > 1. you have to roundtrip whereas in the suspend_blocker scheme you have > active annotations (i.e. no further action needed) That's why it's best to use both. The normal case is that programs activate and deactivate blockers by sending one-way messages to the PM process. The exceptional case is when the PM process is about to initiate a suspend; that's when it does the round-trip polling. Since the only purpose of the polling is to avoid a race, 90% of the time it will succeed. > 2. it may not be possible for a user to determine if a wake-event is > in-flight. you would have to somehow pass the wake-event-number with > it, so that the userspace process could ack it properly without > confusion. Or... I don't know of anything else... > > 1. userspace-manager (UM) reads a number (42). > > 2. it questions userspace program X: is it ok to suspend? > > [please fill in how userspace program X determines to block > suspend] > > 3a. UM's roundtrip ends and it proceeds to write "42" to the > kernel [suspending] > 3b. UM's roundtrip ends and it aborts suspend, because a > (userspace-)suspend-blocker got activated > > I'm not shure how the userspace program could determine that there is a > wake-event in flight. Perhaps by storing the number of last wake-event. > But then you need per-wake-event-counters... :| Rafael seems to think timeouts will fix this. I'm not so sure. > Do you have some thoughts about the wake-event-in-flight detection? Not really, except for something like the original wakelock scheme in which the kernel tells the PM core when an event is over. 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: Alan Stern on 21 Jun 2010 18:30 On Mon, 21 Jun 2010, Rafael J. Wysocki wrote: > > After further thought, there's still a race: > > > > A wakeup event arrives. > > > > The kernel increments /sys/power/wakeup_count and starts > > processing the event. > > > > The power-manager process reads /sys/power/wakeup_count. > > You assume that these two steps will occur instantaneously one after the other, > while there may be (and in fact there should be) a delay between them. No, I'm not assuming that. > I would make the power manager wait for certain time after reading > /sys/power/wakeup_count and if no wakeup events are reported to it within > that time, to write to /sys/power/wakeup_count. Why? That's just wasted time -- time during which the system could have been suspended. I can understand the power manager might reason as follows: If this wakeup event hasn't been handed over to a userspace program in the next 5 seconds, I'm going to suspend anyway on the theory that something is wrong. But why do that when you can get exact information? > The length of the time to wait would be system-dependent in general, but I'd > also allow the event consumers to influence it (like when an application knows > it will process things for 10 minutes going forward, so it tells the power > manager to wait for at least 10 minutes before attempting to suspend). It tells the power manager to wait by activating a userspace suspend blocker. While a blocker is active, the power manager doesn't have to poll /sys/power/wakeup_count or anything; it just waits for all the suspend blockers to be deactivated. And there's no guesswork involved; the power manager knows immediately when it's time to try suspending again. > > The power-manager process polls the relevant programs and > > they all say no events are pending. > > > > The power-manager process successfully writes > > /sys/power/wakeup_count. > > > > The power-manager process initiates a suspend. > > > > ... Hours later ... > > > > The system wakes up. > > > > The kernel finishes its internal processing of the event and > > sends a notification to a user program. > > > > The problem here is that the power-manager process can't tell when the > > kernel has finished processing an event. This is true both for events > > that need to propagate to userspace and for events that are handled > > entirely by the kernel. > > > > This is a reflection of the two distinct pieces of information that we > > need to keep track of: > > > > A wakeup event has arrived, so it's no longer safe to suspend. > > > > Wakeup events are no longer pending, so it's once again > > safe to suspend. > > > > The wakeup_count interface tracks the first, but in this scheme nothing > > tracks the second. > > Which I don't think is really necessary, because we'll need to use timeouts > anyway, at least for events that have no user space consumers. You wouldn't need to use timeouts for them either if the kernel had a way to indicate when it was finished processing events. 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 21 Jun 2010 18:50 On Tuesday, June 22, 2010, Rafael J. Wysocki wrote: > On Tuesday, June 22, 2010, Alan Stern wrote: > > On Mon, 21 Jun 2010, Florian Mickler wrote: > > > > > > In the end you would want to have communication in both directions: > > > > suspend blockers _and_ callbacks. Polling is bad if done too often. > > > > But I think the idea is a good one. > > > > > > Actually, I'm not so shure. > > > > > > 1. you have to roundtrip whereas in the suspend_blocker scheme you have > > > active annotations (i.e. no further action needed) > > > > That's why it's best to use both. The normal case is that programs > > activate and deactivate blockers by sending one-way messages to the PM > > process. The exceptional case is when the PM process is about to > > initiate a suspend; that's when it does the round-trip polling. Since > > the only purpose of the polling is to avoid a race, 90% of the time it > > will succeed. > > > > > 2. it may not be possible for a user to determine if a wake-event is > > > in-flight. you would have to somehow pass the wake-event-number with > > > it, so that the userspace process could ack it properly without > > > confusion. Or... I don't know of anything else... > > > > > > 1. userspace-manager (UM) reads a number (42). > > > > > > 2. it questions userspace program X: is it ok to suspend? > > > > > > [please fill in how userspace program X determines to block > > > suspend] > > > > > > 3a. UM's roundtrip ends and it proceeds to write "42" to the > > > kernel [suspending] > > > 3b. UM's roundtrip ends and it aborts suspend, because a > > > (userspace-)suspend-blocker got activated > > > > > > I'm not shure how the userspace program could determine that there is a > > > wake-event in flight. Perhaps by storing the number of last wake-event. > > > But then you need per-wake-event-counters... :| > > > > Rafael seems to think timeouts will fix this. I'm not so sure. > > > > > Do you have some thoughts about the wake-event-in-flight detection? > > > > Not really, except for something like the original wakelock scheme in > > which the kernel tells the PM core when an event is over. > > But the kernel doesn't really know that, so it really can't tell the PM core > anything useful. What happens with suspend blockers is that a kernel suspend s/suspend/subsyste/ (-ETOOLATE) > cooperates with a user space consumer of the event to get the story straight. > > However, that will only work if the user space is not buggy and doesn't crash, > for example, before releasing the suspend blocker it's holding. > > Apart from this, there are those events withoug user space "handoff" that > use timeouts. > > Also there are events like wake-on-LAN that can be regarded as instantaneous > from the power manager's point of view, so they don't really need all of the > "suspend blockers" machinery and for them we will need to use a cooldown > timeout anyway. > > And if we need to use that cooldown timeout, I don't see why not to use > timeouts for avoiding the race you're worrying about. -- 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 21 Jun 2010 18:50 On Tuesday, June 22, 2010, Alan Stern wrote: > On Mon, 21 Jun 2010, Florian Mickler wrote: > > > > In the end you would want to have communication in both directions: > > > suspend blockers _and_ callbacks. Polling is bad if done too often. > > > But I think the idea is a good one. > > > > Actually, I'm not so shure. > > > > 1. you have to roundtrip whereas in the suspend_blocker scheme you have > > active annotations (i.e. no further action needed) > > That's why it's best to use both. The normal case is that programs > activate and deactivate blockers by sending one-way messages to the PM > process. The exceptional case is when the PM process is about to > initiate a suspend; that's when it does the round-trip polling. Since > the only purpose of the polling is to avoid a race, 90% of the time it > will succeed. > > > 2. it may not be possible for a user to determine if a wake-event is > > in-flight. you would have to somehow pass the wake-event-number with > > it, so that the userspace process could ack it properly without > > confusion. Or... I don't know of anything else... > > > > 1. userspace-manager (UM) reads a number (42). > > > > 2. it questions userspace program X: is it ok to suspend? > > > > [please fill in how userspace program X determines to block > > suspend] > > > > 3a. UM's roundtrip ends and it proceeds to write "42" to the > > kernel [suspending] > > 3b. UM's roundtrip ends and it aborts suspend, because a > > (userspace-)suspend-blocker got activated > > > > I'm not shure how the userspace program could determine that there is a > > wake-event in flight. Perhaps by storing the number of last wake-event. > > But then you need per-wake-event-counters... :| > > Rafael seems to think timeouts will fix this. I'm not so sure. > > > Do you have some thoughts about the wake-event-in-flight detection? > > Not really, except for something like the original wakelock scheme in > which the kernel tells the PM core when an event is over. But the kernel doesn't really know that, so it really can't tell the PM core anything useful. What happens with suspend blockers is that a kernel suspend cooperates with a user space consumer of the event to get the story straight. However, that will only work if the user space is not buggy and doesn't crash, for example, before releasing the suspend blocker it's holding. Apart from this, there are those events withoug user space "handoff" that use timeouts. Also there are events like wake-on-LAN that can be regarded as instantaneous from the power manager's point of view, so they don't really need all of the "suspend blockers" machinery and for them we will need to use a cooldown timeout anyway. And if we need to use that cooldown timeout, I don't see why not to use timeouts for avoiding the race you're worrying about. 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: Arve Hjønnevåg on 21 Jun 2010 21:00
On Mon, Jun 21, 2010 at 3:40 PM, Rafael J. Wysocki <rjw(a)sisk.pl> wrote: > On Tuesday, June 22, 2010, Alan Stern wrote: >> On Mon, 21 Jun 2010, Florian Mickler wrote: >> >> > > In the end you would want to have communication in both directions: >> > > suspend blockers _and_ callbacks. �Polling is bad if done too often. >> > > But I think the idea is a good one. >> > >> > Actually, I'm not so shure. >> > >> > 1. you have to roundtrip whereas in the suspend_blocker scheme you have >> > active annotations (i.e. no further action needed) >> >> That's why it's best to use both. �The normal case is that programs >> activate and deactivate blockers by sending one-way messages to the PM >> process. �The exceptional case is when the PM process is about to >> initiate a suspend; that's when it does the round-trip polling. �Since >> the only purpose of the polling is to avoid a race, 90% of the time it >> will succeed. >> >> > 2. it may not be possible for a user to determine if a wake-event is >> > in-flight. you would have to somehow pass the wake-event-number with >> > it, so that the userspace process could ack it properly without >> > confusion. Or... I don't know of anything else... >> > >> > � � 1. userspace-manager (UM) reads a number (42). >> > >> > � � 2. it questions userspace program X: is it ok to suspend? >> > >> > � � [please fill in how userspace program X determines to block >> > � � suspend] >> > >> > � � 3a. UM's roundtrip ends and it proceeds to write "42" to the >> > � � kernel [suspending] >> > � � 3b. UM's roundtrip ends and it aborts suspend, because a >> > � � (userspace-)suspend-blocker got activated >> > >> > I'm not shure how the userspace program could determine that there is a >> > wake-event in flight. Perhaps by storing the number of last wake-event. >> > But then you need per-wake-event-counters... :| >> >> Rafael seems to think timeouts will fix this. �I'm not so sure. >> >> > Do you have some thoughts about the wake-event-in-flight detection? >> >> Not really, except for something like the original wakelock scheme in >> which the kernel tells the PM core when an event is over. > > But the kernel doesn't really know that, so it really can't tell the PM core > anything useful. �What happens with suspend blockers is that a kernel suspend > cooperates with a user space consumer of the event to get the story straight. > > However, that will only work if the user space is not buggy and doesn't crash, > for example, before releasing the suspend blocker it's holding. > > Apart from this, there are those events withoug user space "handoff" that > use timeouts. > > Also there are events like wake-on-LAN that can be regarded as instantaneous > from the power manager's point of view, so they don't really need all of the > "suspend blockers" machinery and for them we will need to use a cooldown > timeout anyway. > > And if we need to use that cooldown timeout, I don't see why not to use > timeouts for avoiding the race you're worrying about. > Just because some events need to use timeouts, does not mean that all events should use timeouts. You may even want different timeout for different events. If I want a 5 minute timeout after a wake-on-lan packet, I don't want the same timeout after every battery check alarm (every 10 minutes on the Nexus One). Also, I don't see how this patch helps with events that never make reach user-space. Unless each driver blocks suspend by returning and error from its suspend hook, the driver then becomes dependent on the user-space power manager to choose a sufficiently long timeout. For some drivers, like the gpio keypad matrix driver there, is no safe value for the timeout. The keypad driver has to block suspend if any keys are held down. I won't have time to actively follow this discussion, but I don't think this patch is a good solution. -- 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/ |