[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: Felipe Contreras on 5 Jun 2010 16:10 On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler <florian(a)mickler.org> wrote: > On Sat, 5 Jun 2010 20:30:40 +0300 > Felipe Contreras <felipe.contreras(a)gmail.com> wrote: >> I don't think the suspend blockers solve much. A bad application will >> behave bad on any system. Suppose somebody decides to port Firefox to >> Android, and forgets to listen to the screen off event (bad on Android >> or Maemo), however, notices the application behaves very badly, so by >> googling finds these suspend blockers, and enables them all the time >> the application runs. >> >> When the user install the application, will be greeted by a warning >> "This application might break PM, do you want to enable suspend >> blockers?" (or whatever), as any typical user would do, will press Yes >> (whatever). >> >> We end up in exactly the same situation. >> > No. The application will show up in the suspend blocker stats and the > user will remember: "Oh, yes. There was a warning about that. Well I > think I'm going to file a bug there." 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). > 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. -- 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: Felipe Contreras on 5 Jun 2010 16:30 On Sat, Jun 5, 2010 at 11:01 PM, Florian Mickler <florian(a)mickler.org> wrote: > On Sat, 5 Jun 2010 20:44:24 +0300 > Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > >> 2010/6/2 Arve Hjønnevåg <arve(a)android.com>: >> > 2010/6/2 Peter Zijlstra <peterz(a)infradead.org>: >> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're >> >> fixing it, get over it already). >> >> >> > >> > I don't think it is realistic to drop support for all existing hardware. >> >> We are talking about mainline here, there's no support for suspend >> blockers, so nothing is dropped. >> >> In the mind of everybody, suspend blockers is for opportunistic >> suspend, which only makes sense on sensible hw (not current x86). So >> in the mind of everybody, x86 should be out of scope for the analysis >> of suspend blockers. >> >> Are you seriously suggesting that one of the strong arguments in favor >> of suspend blockers is x86 usage (nobody agrees)? If not, then drop >> it. > > I think they have an advantage over the > 30-minute-screensaver-then-suspend that current desktops do. Because > you can define what keeps the system up. I.e. the > screensaver/powermanager is not limited to keyboard- and > mouse-inactivity. What prevents you from defining other things keeping the system up right now? Nothing. It's up to user-space to decide when to suspend. In fact applications already block suspend; Transmission has the option to block suspend when downloading torrents. >> If I enable suspend blockers on my laptop, I have to modify my >> user-space. Otherwise my system will behave horribly. >> > > In the simplest case you have a shell script which takes a suspend > blocker and reads from stdinput. When you write "mem" to it, it > releases the suspend blocker and acquires it back again. Voila, forced > suspend reimplemented on top of opportunistic suspend. > > That wasn't hard, was it? Not hard, but still a modification of user-space, and a pretty bad one because it will prevent typical forced suspend, and typical suspend delaying (like with Transmission). Supposing the opportunistic suspend doesn't block the forced suspend, still, absolutely nothing will be achieved by enabling suspend blockers. If you want to take even a minimal advantage of suspend blockers you need serious modifications to user-space. Supposing there's a perfect usage of suspend blockers from user-space on current x86 platforms (in theory Android would have that), is the benefit that big to consider this a strong argument in favor of suspend blockers? Considering the small amount of x86 platforms using Android (is there any?), the fact that nobody else will use suspend blockers, and that x86 is already being fixed (as mentioned many times before) so dynamic PM is possible, I don't think we should be considering current x86 at all for 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: Florian Mickler on 5 Jun 2010 17:00 On Sat, 5 Jun 2010 23:06:03 +0300 Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler <florian(a)mickler.org> wrote: > > On Sat, 5 Jun 2010 20:30:40 +0300 > > Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > >> I don't think the suspend blockers solve much. A bad application will > >> behave bad on any system. Suppose somebody decides to port Firefox to > >> Android, and forgets to listen to the screen off event (bad on Android > >> or Maemo), however, notices the application behaves very badly, so by > >> googling finds these suspend blockers, and enables them all the time > >> the application runs. > >> > >> When the user install the application, will be greeted by a warning > >> "This application might break PM, do you want to enable suspend > >> blockers?" (or whatever), as any typical user would do, will press Yes > >> (whatever). > >> > >> We end up in exactly the same situation. > >> > > No. The application will show up in the suspend blocker stats and the > > user will remember: "Oh, yes. There was a warning about that. Well I > > think I'm going to file a bug there." > > 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. > > > 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? Cheers, Flo -- 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 17:20 On Sat, 5 Jun 2010 23:26:27 +0300 Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > Supposing there's a perfect usage of suspend blockers from user-space > on current x86 platforms (in theory Android would have that), is the > benefit that big to consider this a strong argument in favor of > suspend blockers? Considering the small amount of x86 platforms using > Android (is there any?), the fact that nobody else will use suspend > blockers, and that x86 is already being fixed (as mentioned many times > before) so dynamic PM is possible, I don't think we should be > considering current x86 at all for suspend blockers. A solution for the desktop to deprecate having to shut down the machine would not be that bad, wouldn;t it? (Why have I to shut down my machine anyway?) In my opinion such a decision (when to shutdown) has to be guided by userspace knowledge. Future x86 hardware is to be fixed (as I read in this discussion), so using suspend blockers could be the tool of choice. But alright. Let's be a little bit more focused on the present situation: 1) There currently is no other solution. 2) It is a first stepping stone to bringing android to mainline. 3) Any "perfect" solution will emerge anyway. As there are so many people with so strong opinions engaged in this discussion, I'm confident. 4) If there is a better solution, android will shurely adapt it as soon as it is there. Cheers, Flo -- 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 17:40
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") -- 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/ |