[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Thomas Gleixner on 5 Jun 2010 17:50 On Sat, 5 Jun 2010, Florian Mickler wrote: > On Sat, 5 Jun 2010 23:24:40 +0200 (CEST) > Thomas Gleixner <tglx(a)linutronix.de> wrote: > > > Stop that advertising campaing already. > > Stop advertising that there is no problem. > > > > > No thanks, > > > > tglx > > Cheers, > Flo > > (Sorry, crossfire. Caused > by you answering in the wrong subthread. I know that you are > engineering and not dismissing the problem. This was pointed at > Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well") Welcome to my killfile. -- 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: Florian Mickler on 5 Jun 2010 18:00 On Sat, 5 Jun 2010 22:56:45 +0300 Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler <florian(a)mickler.org> wrote: > > On Sat, 5 Jun 2010 20:16:33 +0300 > > Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > >> New users will see it has low score; they will not install it. That's > >> a network effect. > >> > >> Having users is the quintessential reason people write code. > > > > That is nice. But how does it impact the problem that suspend blockers > > solve? And why do suspend blockers interfere with that? > > It doesn't, I don't know why people keep bringing this argument, I > just though it should not be left open as a valid one. > > I should have mentioned that this is indeed irrelevant. > Uh! I found out how this is relevant to the suspend blockers case. Because not having users means that the bugs don't get fixed. Whereas in the suspend blockers case the users can use the app and get the bugs fixed. Cheers, Flo p.s.: I really wished you would focus more on solving the problem and not on dismissing it. -- 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 Contreras on 9 Jun 2010 04:20 On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler <florian(a)mickler.org> wrote: > On Sat, 5 Jun 2010 23:06:03 +0300 > Felipe Contreras <felipe.contreras(a)gmail.com> wrote: >> How would such stats be calculated? I presume at regular intervals you >> check which applications are holding suspend blockers and increase a >> counter. >> >> How would you do that with the dynamic PM approach? At regular >> intervals you check for which applications are running (not idle). > > IIRC, the patches discussed have debugging infrastructure in > them. The kernel does the accounting. We are not talking about debugging, we are talking about stats shown in user-space so that users can see the offending apps. It doesn't matter where the accounting is done, it would be at regular intervals and there's nothing that prevents the dynamic PM approach to offer similar stats. >> > The only difference is, that with suspend blockers, he can than >> > dismiss the applications permission to block suspend and will not miss >> > his job interview the next day because his phones battery run >> > out. And also he can use the application to a certain extent. >> >> So the difference is between removing the app, and making it run >> crappy. I don't think that's a strong argument in favor of suspend >> blockers. >> > If you think a little about it, it is. Because if the app wouldn't be > usable at all, the bug wouldn't get fixed because the user wouldn't use > it. Or not? I'm not sure what's your point here. One user not using a certain application doesn't prevent bugs to get fixed. In fact, less people using an app will cause less buzz, and less downloads, and less positive votes... which might wake up the author to think: hey, maybe I'm doing something wrong? Maybe I should really listen to those bug reports. Anyway, my point is that there's nothing special about 3rd party app stats with suspend blockers. -- Felipe Contreras -- 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 22 Jun 2010 07:20
Hi! (ok, so I'm little late to the party). > > Nonsense, if we want to push the system into suspend from the idle > > state we can do that. It's just not implemented and we've never tried > > to do it as it requires a non trivial amount of work, but I have done > > it on an ARM two years ago as a prove of concept and it works like a > > charm. > > ACPI provides no guarantees about what level of hardware functionality > remains during S3. You don't have any useful ability to determine which > events will generate wakeups. And from a purely practical point of view, We'll need ACPI extensions, then (or very conservative drivers). suspend blockers do *not* help here. > since the latency is in the range of seconds, you'll never have a low > enough wakeup rate to hit it. I did 'sleepy linux' prototype on PC, and yes I was able to get to 'once in 5 seconds' wakeup rate... good enough... Pavel -- (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/ |