[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: Alan Stern on 14 May 2010 22:40 On Fri, 14 May 2010, Rafael J. Wysocki wrote: > > > 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 record, waking to interrupts doesn't work on quite some systems > (like ACPI-based PCs for one example). Ironically, it appears that ACPI-based PCs are in a position to benefit more from opportunistic suspend and suspend blockers than are embedded systems -- and yet they are being proposed for use on cell phones rather than on desktops. 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 14 May 2010 22:50 On Fri, 14 May 2010, Magnus Damm wrote: > I agree with you Tony. I thought shutting down CPUs for power > managment purposes could be done without freezing user space. At least > that's what we do today with SH-Mobile. If you can shut down and restart CPUs in the time periods between transitions into and out of the idle loop, then yes -- userspace doesn't need to be suspended. After all, if the idle loop is running then no user threads are runnable. (Not necessarily true on SMP systems, but you know what I mean.) > Still not sure how the system wide suspend is different from Runtime > PM and CPUidle from the hardware perspective... For embedded systems, apparently the difference is minimal. For other systems, like ACPI-based PCs, there is a big difference: Powering down devices and CPUs still leaves large parts of the system running. In addition, these larger systems generally don't have aggressive runtime PM support, so a significant fraction (maybe more than 50%) of devices won't be powered down when they are idle -- whereas system suspend powers virtually everything down. 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 14 May 2010 23:00 On Fri, 14 May 2010, Brian Swetland wrote: > It provides useful functionality -- you apparently disagree, but the > wakelock/suspendblock model is in use, shipping, and solving problems > for quite a lot of android devices that have been shipping for a while > now. We actively go to lowest power state in idle (on omap, msm, > etc), and use drivers that aggressively declock and depower modules > (similar to runtime pm), but we have found that using the > opportunistic suspend model combined with wakelocks allows us to > attain even lower average power consumption in always-connected, > actively-syncing devices. Can you explain this in more detail? Are you saying that some devices go on generating interrupts and causing timers to be scheduled, even though what they're doing isn't important enough to prevent the system from powering down? 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: Brian Swetland on 14 May 2010 23:50 On Fri, May 14, 2010 at 7:58 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Fri, 14 May 2010, Brian Swetland wrote: > >> It provides useful functionality -- you apparently disagree, but the >> wakelock/suspendblock model is in use, shipping, and solving problems >> for quite a lot of android devices that have been shipping for a while >> now. We actively go to lowest power state in idle (on omap, msm, >> etc), and use drivers that aggressively declock and depower modules >> (similar to runtime pm), but we have found that using the >> opportunistic suspend model combined with wakelocks allows us to >> attain even lower average power consumption in always-connected, >> actively-syncing devices. > > Can you explain this in more detail? Are you saying that some devices > go on generating interrupts and causing timers to be scheduled, even > though what they're doing isn't important enough to prevent the system > from powering down? In tickless mode, the time until next timer is a signed int, so the longest the kernel will ever sleep is ~2 seconds at a go. In practice, userspace entities often have polling behavior that can trigger more often than that, and I've observed some kernel periodic timers (haven't cataloged them recently) that happen more often than once a second. When we go to full suspend, we know that only specific wakeup sources (keyboard gpios, baseband voice/ip events, rtc alarms, etc) are going to wake us up. Brian -- 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 15 May 2010 00:10
On Fri, May 14, 2010 at 7:35 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Fri, 14 May 2010, Rafael J. Wysocki wrote: > >> > > 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 record, waking to interrupts doesn't work on quite some systems >> (like ACPI-based PCs for one example). > > Ironically, it appears that ACPI-based PCs are in a position to benefit > more from opportunistic suspend and suspend blockers than are embedded > systems -- and yet they are being proposed for use on cell phones > rather than on desktops. > I would also use it on a desktop. -- 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/ |