[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: David Brownell on 20 May 2010 19:10 > -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. Or something as broken as a non-terminating CPU loop ... Of course not. But if there's a kernel mechanism exposed to userspace which really sucks down power ... either it's done correctly and the problem is userspace abusing it, or it's done wrong so that it's not possible to be used correctly. There are some things that just cost power, and that cost can't be escaped. -- 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 25 May 2010 04:00 Hi! > > There are several general problems with the design of opportunistic > > suspend and suspend-blocks. > > > > 1. The opportunistic suspend code bypasses existing Linux kernel code, > > such as timers and the scheduler, that indicates when code > > needs to run, and when the system is idle. > > Whoa! That's not my understanding at all. > > As I see it, opportunistic suspend doesn't bypass any code that isn't > already bypassed by the existing suspend code. Users can do > > echo mem >/sys/power/state > > whenever they want, without regard to kernel timers and the scheduler > (other than the fact that the user's thread must be running in order to > carry out the write, of course). Yep. And while I'm co-responsible for that interface, I would not call it exactly nice. Yes, it does the job. But imagine horrors atd/cron would have to do to work properly with that interface... setting rtc wakeups etc. So yes, mem > state already breaks promises, but lets not extend that. -- (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: Pavel Machek on 25 May 2010 04:00
On Thu 2010-05-13 21:08:14, Matthew Garrett wrote: > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > > > The system stays running because there's something to do. The system > > won't suspend until all the processors hit the kernel idle loop and > > the next_timer_interrupt_critical() returns nothing. > > At which point an application in a busy loop cripples you. I think we Application running busy loop already cripples you, with power going from 15W to 50W in thinkpad case. Just avoid badly written apps. -- (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/ |