Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Felipe Contreras on 12 Aug 2010 12:50 On Thu, Aug 12, 2010 at 3:52 PM, Ted Ts'o <tytso(a)mit.edu> wrote: > On Thu, Aug 12, 2010 at 03:28:01PM +0300, Felipe Contreras wrote: >> >> The question is why are we adding a user-space API that: >> 1) no user-space beside Android has expresses interest in implementing >> 2) is dubious whether the benefits are worth the pain for non-Android >> user-space >> 3) will become less and less attractive as dynamic PM gets closer to >> the sweet-spot, and then surpass it >> 4) Android can keep in a separate tree until it's clear in the linux >> community that it's useful (if it ever happens) > > Do you believe you speak for all of LKML? No. I'm speaking for myself, and that includes a lot of what people on LKML have already said. > Are you willing to tell ZDNet and the Slashdot fanboys that it's OK > for Suspend blockers to live in a separate tree, and it's not a case > of OMG! Google is forking the kernel? All the Android community had to do is push the drivers *without* suspend blockers, then the Android kernel wouldn't be so different and thus wouldn't be considered a fork. AFAIU the kernel side wakelocks are already in the kernel, so there's no excuse not to merge the drivers. Then people would stop blaming Google for forking the kernel. Nobody from the "media" cares about suspend blockers; they are a small patch which cannot be considered a fork, more like a hack, like many other platforms have. -- 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 12 Aug 2010 13:00 On Thu, Aug 12, 2010 at 5:09 PM, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote: > >> So far, nobody has refuted these: >> 1) opportunistic suspend needs a good behaved user-space to work properly >> 2) if suspend blockers are enabled in a system, *all* user-space must >> implement them to work correctly > > For this note that there's a fairly strong expectation that even in a > phone type environment a sane userspace implementation will involve a > very large portion of userspace just totally ignoring suspend blockers. > This means that while it is true that userspace as a whole must have > support for suspend blockers the changes required are substantially less > invasive than you appear to expecting. Correct, but still a considerable amount of changes would need to be done, which _nobody_ has expressed any intention to do. Besides, IMO a good mobile platform would share as much as possible with desktop software. Say, the improvements Nokia has endorsed on the Telepathy IM framework can only help the people already using it on the desktop. However, personally, if I ever have to do './configure --enable-suspend-blockers', I would think that something that just doesn't belong has creped by to user-space. I don't see why there should something particularly different between mobile phones and laptops, and I think this has been already expressed over, and over. -- 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: Brian Swetland on 12 Aug 2010 13:40 On Thu, Aug 12, 2010 at 9:57 AM, Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > > Correct, but still a considerable amount of changes would need to be > done, which _nobody_ has expressed any intention to do. > > Besides, IMO a good mobile platform would share as much as possible > with desktop software. Say, the improvements Nokia has endorsed on the > Telepathy IM framework can only help the people already using it on > the desktop. > > However, personally, if I ever have to do './configure > --enable-suspend-blockers', I would think that something that just > doesn't belong has creped by to user-space. I don't see why there > should something particularly different between mobile phones and > laptops, and I think this has been already expressed over, and over. So, because you feel that phones should be little laptops you oppose providing (optional!) support for environments that take a different view to that? I'll echo Ted's question -- is this the opinion of the kernel community at large? If so, there's not much point in continuing to have discussions around suspend blockers. I think that we're still a ways away from a world where we can treat mobile devices the same as laptops and get reasonable user experiences. I think it's unfortunate if the attitude here is "wait and someday it won't matter", especially because I'm skeptical that we're likely to hit that "someday" any time soon. 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: Paul E. McKenney on 12 Aug 2010 13:50 On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote: > On Thu, Aug 12, 2010 at 1:47 PM, Theodore Tso <tytso(a)mit.edu> wrote: > > One thing I'm not clear on --- what's your goal? � Is your goal to keep suspend-blockers out of the kernel? � Is it to try to convince the android team suspend-blockers are a bad idea and to change Android to not use them? �Is it to push some other agenda? �Is it to discourage the Android team from trying to waste more time trying to get suspend-blockers (or equivalent functionality) from being added into the kernel? > > My goal is to shine light. I've heard many invalid arguments in favor > of suspend blockers, I want to shut them down. > > In my mind it's crystal clear that independently of what opportunistic > suspend is supposed to be fixing, the fact of the matter is that it's > not a silver bullet as it's claimed to be. The question is not whether suspend blockers are a silver bullet (in my opinion there are no silver bullets), but rather whether or not suspend blockers are useful. > So far, nobody has refuted these: > 1) opportunistic suspend needs a good behaved user-space to work properly As does dynamic power management. > 2) if suspend blockers are enabled in a system, *all* user-space must > implement them to work correctly Really? From what I can see, only PM-driving applications need to use suspend blockers. > 3) implementing suspend blockers in user-space is not a straight-forward task Fortunately, experience thus far has shown that only a small fraction of applications need to use suspend blockers. (Or perhaps you are instead saying that the implementation of the suspend-blocker infrastructure itself is not straightforward? It is not clear from your words.) > 4) there's a point where sleeping (not doing work) has diminished returns This one I agree with. > So, as the length of this thread has shown, the benefits of > opportunistic suspend are *dubious* at best, and more likely not worth > the changes needed in user-space which eventually will get pretty > close to what suspend blockers can achieve even in ideal circumstances > by just doing dynamic PM. The length of this thread (and the ones preceding it) is mostly due to people talking past each other. For example, the Android folks seem to believe that it is important that relatively unskilled people be able to write simple apps, and that the system nevertheless be able to run these apps in a relatively energy efficient manner. Your proposals do not address this issue. This might be because you are not aware of this desire, because you are not aware of the computing history that argues in favor of this requirement, or because you simply don't like this requirement. Whatever the reason, until you face this requirement head on, either addressing it or proving that it need not be addressed, you will continue to be talking past the Android folks. Thanx, Paul -- 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 12 Aug 2010 14:00
On Thu, Aug 12, 2010 at 7:19 PM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Thu, Aug 12, 2010 at 03:17:29AM +0300, Felipe Contreras wrote: >> Anyway, Alan was picturing a hypothetical point in time when x86 can >> suspend/resume as fast as ARM, and thus the question of whether or not >> to enable suspend-blockers in a system that runs openoffice becomes >> relevant. If applications have been fixed by that time to not wake the >> system unnecessarily, as many of them have already been tanks to tools >> like powertop, then suspend-blockers would not make that much of a >> difference, therefore the effort required to implement >> suspend-blockers properly on all applications in the system, including >> openoffice might not be worth the gain. > > One more time, this time with feeling. ;-) > > Only PM-driving applications need concern themselves with suspend > blockers, and experience thus far indicates that PM-driving > applications are a very small fraction of the total. There's no experience on this. Have you tried to run a small debian system with suspend blockers enabled? I can image at least all cron daemons need modifications, probably dbus, links, lftp, wget, rsync and a bunch of applications that download data too. It's easy to speculate one way or the other, but the fact of the matter is that we don't really know how many changes are needed in order to have a functional system that actually benefits from suspend blockers. What we know is that if an application is not analyzed to see if it needs suspend blockers, and implement them if needed, it might get broken. >> > Apparently different people in this debate have different targets. >> >> I remember clearly Android people explaining that dynamic PM is >> orthogonal to suspend-blockers; if a suspend is blocked, you still >> want dynamic PM to reach the lower power state. Therefore the target >> of not having unneeded runnable tasks is shared by Android folks. > > And I have not seen anyone argue that suspend blockers are a replacement > for dynamic power management. That's exactly what I'm saying: they are orthogonal. > In contrast, you are advocating dynamic power management to the exclusion > of other mechanisms. * if dynamic PM was perfect, spend-blockers would *not* be not needed * if suspend-blockers were perfect, dynamic *will* still be needed All I said in that sentence you are replying is that dynamic PM will improve; it's a shared goal of everyone. >> IOW. Alan wasn't talking about idle vs suspend on the same device, he >> was talking about opportunistic suspend vs dynamic PM. > > The most convincing comparisons will be of suspend vs. idle on the > same device. If multiple devices are involved, then the most convincing > experiments would compare suspend vs. idle separately on each device. > > So, are you sure that you are correctly interpreting Alan's words? The point you are trying to highlight is to which events the system reacts, that has nothing to do with dynamic PM vs opportunistic suspend. > Again, I am in no way arguing for suspend blockers to the exclusion of > other approaches. Heck, I am mostly just trying to get a clear statement > of the problem. In contrast, you do seem to be advocating for dynamic > power management to the exclusion of other approaches. What you are doing is copy pasting a definition of what is opportunistic suspend and making it pass as an advantage. This particular point (3.) is not an advantage, over dynamic PM, it's just a difference. >> No, I think both (for opportunistic suspend and dynamic PM) are >> completely reasonable. But think again; if you have the assumptions >> met on both, then both work fine, if you don't meet them, then both >> don't work correctly. > > That is true of any artifact, software or otherwise: if you don't meet the > assumptions inherent in its design and construction, the artifact might > fail. [...] > There is > a very real difference between those two tasks. I've cut most of your explanation. If I understand correctly what you are saying is that suspend blockers are harder to get wrong. I agree, but my point against 4. remains the same: suspend-blockers don't automatically get you more efficient power usage. > So are you sure that dynamic power management will turn out to be > the right tool for every job out there? If so, on what grounds? I don't understand this question. Dynamic PM is needed regardless. We are discussing your point 4 where you say suspend blockers inevitably lead to more efficient power usage (I say not necessarily). >> My point is that suspend-blockers don't magically reduce power usage, >> just like dynamic PM, it depends on what user-space actually does. You >> made it look as it *always* reached better energy efficiency. > > I do? Really??? Exactly what did I say to give you that impression? Here's your point 4 again: > >> > 4. Suspend generally forces devices to go into their low-power > >> > states immediately. In contrast, idle generally leaves unused > >> > devices at full power, relying on timers to shut down these > >> > devices. Idle thus has shorter average wakeup latencies, but > >> > worse energy efficiency. Remove "but worse energy efficiency" and I think that point would be correct, albeit it's not really an argument in favor of opportunistic suspend. >> > It seems to me that the same social-engineering approaches work in >> > both cases. >> >> Yes, but if dynamic PM works as advertised, you don't need >> opportunistic suspend. > > For dynamic power management to totally eliminate the need for something > like suspend blockers, you are having to make some brave assumptions. > Yes, dynamic power management is quite useful, but there is a big > difference between something being useful and something doing everything > for everyone. You have not yet convinced me that dynamic power management > will make it to the "doing everything for everyone" stage. As it has been explained before, there's a sweet-spot of idleness: http://article.gmane.org/gmane.linux.kernel/995525 http://article.gmane.org/gmane.linux.ports.arm.omap/37982 Do you agree that there's such a thing, and if so, do you agree that the benefits of opportunistic suspend are much less once that point is reached? >> >> If not, you'll see much worst energy efficiency. So in theory maybe, >> >> but in practice you can't say that. >> > >> > Really? What makes you say that? >> >> For starters an application might be holding the wakelock more than it >> should, also, an application might miss a timer due to not having PM >> permissions to hold the lock, and thus might need an expensive >> initialization when it runs again. > > Just as an application might run continuously without blocking, which > would defeat the dynamic power management scheme that have thus far been > put forward. And just as an application might miss a timer due to > dynamic power management having decided that it didn't need that timer > to fire at the desired time. You are making this discussion entropic, concentrate on what I said: >>>> If not, you'll see much worst energy efficiency. So in theory maybe, >>>> but in practice you can't say that. I just proved to you that in certain cases opportunistic suspend might actually hurt. Thus you should accept my premise that you can't say that in practice opportunistic suspend _always_ leads to better results, because that's not the case. And in order to try to avoid going back to the same points: 1) yes, there are advantages of opportunistic suspend 2) yes, there are cases where it works as it should 3) no, it's not a silver bullet that will inevitably improve power usage 4) no, we can't say anything about what opportunistic suspend means in practice -- 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/ |