PM: Opportunistic suspend support.
in [Kernel]
|
Prev: direct-io: do not merge logically non-contiguous requests
Next: [PATCH] linux/elfcore.h: hide kernel functions
From: Peter Zijlstra on 26 May 2010 12:30 On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote: > > Or make the suspend manager a C proglet and provide a JNI interface, > > or whatever. > > It's a fairly large piece of code to try to rewrite in C, so I don't > think that's feasible on a reasonable timescale. Android does have the > concept of special sockets that can be used to communicate from less to > more privileged processes (it has a very segmented runtime model), so > these might be usable ... they have a drawback that they're essentially > named pipes, so no multiplexing, but one per suspend influencing C > process shouldn't be a huge burden. It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state. Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus. The whole idea of segregating userspace like that, and not letting runnable thing run is very ill considered indeed. -- 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: Kevin Hilman on 26 May 2010 12:40 Peter Zijlstra <peterz(a)infradead.org> writes: > Anyway, I think there's been enough arguments against even the concept > of opportunistic/auto-suspend, and I for one will object with a NAK if > Rafael send this to Linus. It's already been submitted to Linus for 2.6.35, but not on LKML: https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025811.html Kevin -- 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 26 May 2010 13:00 On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote: > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote: > > > Or make the suspend manager a C proglet and provide a JNI interface, > > > or whatever. > > > > It's a fairly large piece of code to try to rewrite in C, so I don't > > think that's feasible on a reasonable timescale. Android does have the > > concept of special sockets that can be used to communicate from less to > > more privileged processes (it has a very segmented runtime model), so > > these might be usable ... they have a drawback that they're essentially > > named pipes, so no multiplexing, but one per suspend influencing C > > process shouldn't be a huge burden. > > It wouldn't need to convert the whole Frameworks layer into C, just > enough to manage the suspend state. > > Anyway, I think there's been enough arguments against even the concept > of opportunistic/auto-suspend, and I for one will object with a NAK if > Rafael send this to Linus. It was submitted already. I tried to followup with NAK, but can't currently see it in the archive. 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/
From: James Bottomley on 26 May 2010 13:00 On Wed, 2010-05-26 at 18:28 +0200, Peter Zijlstra wrote: > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote: > > > Or make the suspend manager a C proglet and provide a JNI interface, > > > or whatever. > > > > It's a fairly large piece of code to try to rewrite in C, so I don't > > think that's feasible on a reasonable timescale. Android does have the > > concept of special sockets that can be used to communicate from less to > > more privileged processes (it has a very segmented runtime model), so > > these might be usable ... they have a drawback that they're essentially > > named pipes, so no multiplexing, but one per suspend influencing C > > process shouldn't be a huge burden. > > It wouldn't need to convert the whole Frameworks layer into C, just > enough to manage the suspend state. That's actually what I was saying ... converting the whole frameworks would be impossible. I'm saying the suspend state manager is still a large piece of work. > Anyway, I think there's been enough arguments against even the concept > of opportunistic/auto-suspend, and I for one will object with a NAK if > Rafael send this to Linus. Well, I suppose that's your prerogative. > The whole idea of segregating userspace like that, and not letting > runnable thing run is very ill considered indeed. OK, so this is an approach difference. I see it as controlling an application resource problem, which is similar to quotas on filesystems. The opinion divide seems to come down to those who think the application stack has to be fixed before a working device can be released, and those who want to make the devices work now and supply pressure to fix the applications as well. I fail to see how, in an environment where the whole value of the device is the third party supplied applications that the former view is reasonable. I equally fail to see how the latter is achievable without segregating userspace into trusted and untrusted and taking action to curb the power consumption of untrusted applications. Given that I'm in the latter category, I think suspend blockers is a reasonable solution to an existing problem. I like Alan's idea of restricting the API into a single user space program so we contain the API contamination ... but realistically that's mostly the current suspend blockers anyway. James -- 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: Peter Zijlstra on 26 May 2010 13:10
On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote: > Given that I'm in the latter category, I think suspend blockers is a > reasonable solution to an existing problem. I like Alan's idea of > restricting the API into a single user space program so we contain the > API contamination ... but realistically that's mostly the current > suspend blockers anyway. There's a _large_ difference between resource limits and these wonky suspend blockers. The main and most important one being that suspend is a global property and can/will hurt sensible tasks. It puts the whole task model upside down. -- 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/ |