On Saturday, August 14, 2010, James Bottomley wrote: > On Fri, 2010-08-13 at 15:08 -0400, Ted Ts'o wrote: > > On Fri, Aug 13, 2010 at 01:11:29PM -0400, James Bottomley wrote: > > > > > > The facts are that suspend blockers identifies a race within our suspend > > > to ram system that permeates from top to bottom (that's from server to > > > mobile). The problem is that resume events are racy with respect to > > > suspend and vice versa. This manifests itself most annoyingly on my > > > laptop in the "double suspend" case: where I suspend with a pending > > > suspend event, my laptop will resume and then immediately re-suspend > > > (leading me to kick myself and remind myself to check it stayed up > > > before pushing unsuspend and walking away). The other annoying case is > > > that if I accidentally close the lid before presenting, I have to wait > > > until the system is fully down before pressing resume. > > > > This is all true, but it's also only one aspect of the problem. I > > agree with you that this is the part of the problem which affects > > Linux at all scales, from Cloud servers in a data center that want to > > suspend themselves when there's no work to do (and then fail to > > respond to the WOL packet) to mobile platforms that are suspending > > much more frequently. > > > > However, it doesn't follow that this is the _only_ problem that the > > Android folks might be interested in solving. Opportunistic suspend > > is a different part of the problem space, which is generally believed > > by the Android developers as being far more efficient than a > > user-space suspend manager. Rafael has stated his complete > > unwillingness to deal with this part of the problem. OK, so that > > probably means that for Android, it will have to be an out-of-tree > > kernel patch. > > OK, so I tried desperately to avoid the question of whether > opportunistic suspend is a good way of managing power. However, it > seems to me that it is in use by several systems (android, olpc, etc). > I'll defer the question of whether it's better in user space or kernel > space to Rafael's investigations ... but I will point out that the > kernel space patch, once the suspend blockers issue is taken care of > looks like a single patch to one file, so should be locally containable > and should allow upstream to be useful as the driver base again. > > > The question, then, is whether a solution which addresses the only > > part of the problem which Rafael is interested in dealing with at this > > point, is sufficient such that (a) the kernel-level opportunistic > > suspend can be done as an out-of-tree patch, while simultaneously (b) > > allowing device drivers for Android devices can utilize Rafael's > > interfaces to solve the race design bug currently found in our suspend > > subsystem, while (c) requiring minimal changes to the Android > > userspace, and (d) providing all of the statistics and debugging > > functionality required by the Android userspace. > > > > If we can engineer a solution which meets (a), (b), (c), and (d) > > above, then everyone will be happy. > > That's my goal. In fact, we (which means basically Alan Stern and me at this point) are working with Arve on this right now. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
