[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: Felipe Balbi on 20 May 2010 05:10 On Thu, May 20, 2010 at 10:57:40AM +0200, ext Felipe Balbi wrote: >boder thinking about power consumption since the kernel is "smart" ^I mean bother -- balbi DefectiveByDesign.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: Vladimir Pantelic on 20 May 2010 07:30 Felipe Balbi wrote: > Hi, > > On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote: >>Please note that this approach is not too practical for vendors who ship >>systems like cell phones to the general public. > > yeah, tell me about it :-p > > during development on MeeGo devices we try to tackle down as much as > possible the use_time offenders and start by filing bugs to those apps, > instead of fixing their issues in kernel space. And you will continue doing that once the Meego app store has 100k apps? -- 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: Felipe Balbi on 20 May 2010 07:40 On Thu, May 20, 2010 at 01:27:25PM +0200, ext Vladimir Pantelic wrote: >Felipe Balbi wrote: >> Hi, >> >> On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote: >>>Please note that this approach is not too practical for vendors who ship >>>systems like cell phones to the general public. >> >> yeah, tell me about it :-p >> >> during development on MeeGo devices we try to tackle down as much as >> possible the use_time offenders and start by filing bugs to those apps, >> instead of fixing their issues in kernel space. > >And you will continue doing that once the Meego app store has 100k apps? I'm not here speaking for MeeGo. I'm presenting my own feelings and my own opinion regarding this issue. Don't bring the company into the game, please. -- balbi DefectiveByDesign.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: David Brownell on 20 May 2010 13:50 > > during development on MeeGo devices we try to tackle > down as much as > > possible the use_time offenders and start by filing > bugs to those apps, > > instead of fixing their issues in kernel space. Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to see some fixes be appropriately in-kernel; maybe not many though. When reading about this suspend block stuff, does anyone else hear eachoes of APM? It's been ages since that was used, but ISTR it also leveraged handshaking between kernel and userspace. Are there lessons to be applied from there to this discussion? On first principles, I don't see anything wrong with acknowledging that the kernel doesn't have a "whole system PM view" and thus its PM knowledge could usefully be augmented by information from userspace (applications), possibly on request. Just what that broad PM view consists of gets kind of system-specific. For OMAP hardware, with smart device-level power reduction active almost all the time, it may look different from an ACPI laptop where the BIOS is biased towards saving device power primarily in some suspend state(s) ... or some other hardware platform without much hardware or BIOS assist, where the main PM mechanisms involve software detection/instigation of hardware idleness (and potentially "off-ness"). > And you will continue doing that once the Meego app store > has 100k apps? I may have overlooked it, in one of the 100K messsages in my mailbox about versions of suspend block/etc patches ... But surely NOBODY is actually contending that broken aps NOT get fixed?? It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools. (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.) Once such hogs get identified they will need to get fixed. Any other proposal seems broken to me... -- 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: Felipe Balbi on 20 May 2010 15:00
On Thu, May 20, 2010 at 10:40:17AM -0700, David Brownell wrote: > Some apps do abuse kernel mechanisms, and whether the bug is in the > app or that kernel mechanism can be a judgement call. I'd expect to hey come on, there's no judgement call for an app polling every second to check battery status or some other status that doesn't change that frequently. > I may have overlooked it, in one of the 100K messsages in my mailbox > about versions of suspend block/etc patches ... > > But surely NOBODY is actually contending that broken aps NOT get > fixed?? > > It's clear to me that tools are needed to identify power hogs; > powertop can't be the extent of such tools. (ISTR it doesn't monitor > display power usage, for one thing; maybe newer versions do so.) Once > such hogs get identified they will need to get fixed. Any other > proposal seems broken to me... that's my feeling too. I don't see any needs for suspend blockers in any real system. I acknowledge we need tools probing power consumption to be shipped to production device, that's a good idea, but forcing apps to modify just to have that UI fill up some treeview, I think it's a bit too much. -- balbi -- 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/ |