PM: Add suspend block api.
in [Kernel]
|
Prev: A share can be mounted multiple times on the same mountpoint when using the option 'noac'
Next: parport_pc.c and parport_serial.c need improvements
From: Alan Stern on 6 May 2010 15:50 On Thu, 6 May 2010, Rafael J. Wysocki wrote: > > Here's a completely new issue. When using opportunistic suspends on an > > SMP system, it could happen that the system gets a wakeup event and > > this routine starts running again before the event's IRQ handler has > > finished (or has enabled a suspend blocker). The system would > > re-suspend too soon. > > This routine will be run from a freezable workqueue. But how do you know that processes won't get unfrozen until all the pending IRQs have been handled? Imagine something like this: CPU 0 CPU 1 ----- ----- Wake up non-boot CPUs Resume devices Invoke the IRQ handler [ CPU 0 should wait here for the handler to finish, but it doesn't ] Defrost threads Handler running... Workqueue routine runs Start another suspend Handler enables a suspend blocker, but it's too late 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: Arve Hjønnevåg on 6 May 2010 19:50 On Thu, May 6, 2010 at 12:40 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Thu, 6 May 2010, Rafael J. Wysocki wrote: > >> > Here's a completely new issue. �When using opportunistic suspends on an >> > SMP system, it could happen that the system gets a wakeup event and >> > this routine starts running again before the event's IRQ handler has >> > finished (or has enabled a suspend blocker). �The system would >> > re-suspend too soon. >> >> This routine will be run from a freezable workqueue. > > But how do you know that processes won't get unfrozen until all the > pending IRQs have been handled? �Imagine something like this: > > � � � �CPU 0 � � � � � � � � � CPU 1 > � � � �----- � � � � � � � � � ----- > � � � �Wake up non-boot CPUs > � � � �Resume devices � � � � �Invoke the IRQ handler > > � � � �[ CPU 0 should wait here for the handler to finish, > � � � � �but it doesn't ] > > � � � �Defrost threads � � � � Handler running... > � � � �Workqueue routine runs > � � � �Start another suspend > � � � � � � � � � � � � � � � �Handler enables a suspend blocker, > � � � � � � � � � � � � � � � �but it's too late It is not optimal, but it is not too late. We check if any suspend blockers block suspend after disabling non-boot cpus so as long as this is done in a way that does not lose interrupts the resuspend attempt will not succeed. -- 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: Alan Stern on 7 May 2010 10:30 On Thu, 6 May 2010, Arve Hj�nnev�g wrote: > On Thu, May 6, 2010 at 12:40 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > > On Thu, 6 May 2010, Rafael J. Wysocki wrote: > > > >> > Here's a completely new issue. �When using opportunistic suspends on an > >> > SMP system, it could happen that the system gets a wakeup event and > >> > this routine starts running again before the event's IRQ handler has > >> > finished (or has enabled a suspend blocker). �The system would > >> > re-suspend too soon. > >> > >> This routine will be run from a freezable workqueue. > > > > But how do you know that processes won't get unfrozen until all the > > pending IRQs have been handled? �Imagine something like this: > > > > � � � �CPU 0 � � � � � � � � � CPU 1 > > � � � �----- � � � � � � � � � ----- > > � � � �Wake up non-boot CPUs > > � � � �Resume devices � � � � �Invoke the IRQ handler > > > > � � � �[ CPU 0 should wait here for the handler to finish, > > � � � � �but it doesn't ] > > > > � � � �Defrost threads � � � � Handler running... > > � � � �Workqueue routine runs > > � � � �Start another suspend > > � � � � � � � � � � � � � � � �Handler enables a suspend blocker, > > � � � � � � � � � � � � � � � �but it's too late > > It is not optimal, but it is not too late. We check if any suspend > blockers block suspend after disabling non-boot cpus so as long as > this is done in a way that does not lose interrupts the resuspend > attempt will not succeed. Is it possible for the resuspend to disable CPU 1 before the IRQ handler can enable its suspend blocker? (Probably not -- but I don't know enough about how non-boot CPUs are enabled or disabled.) 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: Pavel Machek on 18 May 2010 09:20 On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote: > Adds /sys/power/policy that selects the behaviour of /sys/power/state. > After setting the policy to opportunistic, writes to /sys/power/state > become non-blocking requests that specify which suspend state to > enter Yeah, one file selects behavior of another file, and to read available states for opportunistic, you have to write to file first. I still don't like the interface. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: Tejun Heo on 20 May 2010 04:40
Hello, (sorry about late reply) On 04/30/2010 07:26 PM, Oleg Nesterov wrote: > Currently _cpu_down() can't flush and/or stop the frozen cwq->thread. > > IIRC this is fixable, but needs the nasty complications. We should > thaw + stop the frozen cwq->thread, then move the pending works to > another CPU. Oh, this isn't an issue w/ cmwq. While frozen all new works are collected into per-cpu delayed worklist and while frozen trustee in charge of the cpu will keep waiting. Once thawed, trustee will execute all works including the delayed ones unbound to any cpu. Thanks. -- tejun -- 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/ |