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: James Bottomley on 26 May 2010 13:40 On Wed, 2010-05-26 at 19:23 +0200, Peter Zijlstra wrote: > On Wed, 2010-05-26 at 12:14 -0500, James Bottomley wrote: > > On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote: > > > 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. > > > > Well, you have policy and then you have implementation ... suspend > > blockers just looks like an implementation to me. It seems to be > > reasonably well suited in that regard ... after all, we kill processes > > that exhaust memory for instance or cut off write privileges to those > > that go over quota. Preventing power hungry processes from consuming > > power by not allowing them to run until there's a wakeup event is fairly > > gentle by those standards. > > The difference is that the limit should be per task. How? You've got two different limits ... one the power the application should be consuming when doing useful work for the user and the other is the idle power. A badly constructed app may only be bad on idle power ... how is the scheduler going to detect this, exactly? And what do we do to applications we've detected are over consuming idle power? > In this model a > process that only runs a little still gets suspended. That's why I think it looks like a reasonable solution. For this to work, I agree you have to have all events the user is interested in wake the system up ... but on most embedded platforms, they do. > > > 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. > > > > OK, so I believe you have an android phone ... it already implements > > this model ... specifically what are the problems on that platform this > > causes? > > I do not have one, nor have I ever written an application for it (nor > will I likely ever do that, since I detest Java), but I would expect an > application to run when its runnable. OK, so I've got one ... tell me what I should see and I'll try to reproduce. 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: James Bottomley on 26 May 2010 13:50 On Wed, 2010-05-26 at 20:25 +0300, Pekka Enberg wrote: > Hi James, > > On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote: > >> Yup, I don't quite get Arve's argument either. C code can interact > >> with Java code (and vice versa) just fine in userspace. > > On Wed, May 26, 2010 at 7:18 PM, James Bottomley > <James.Bottomley(a)suse.de> wrote: > > This is an incorrect statement. It's possible for java to call C via > > the JNI, even though there are quite a few gotchas that mean not just > > *any* C code can do it (been there, tripped over some of them, although > > they were all ultimately ironed out). It's very difficult for C to call > > directly into Java without being specially coded because it involves > > creating and managing a JVM (so in general, arbitrary C code can't do > > this). The usual way we do C -> Java is process to process via some > > intermediary like RPC or Corba or SOAP (or even JSON) ... which gets > > very messy for a mobile device. > > Incorrect statement how exactly? A JVM can do mmap(), for example, > just fine through FileChannel.map() so there's no need for > heavy-weight RPC. Incorrect in that an arbitrary C application can't link to a java API. mmap and some other messaging (like signals) is just another form of IPC ... the list I gave wasn't exhaustive. > Furthermore, the whole discussion is moot anyway as > Android runs Dalvik which can be hacked to support whatever > communication mechanism is the best choice here. > > So can we drop the whole "we need to do it in kernel because Java is > hard" nonsense and concentrate on real issues? I've lost you. This argument seems to hinge on whether or not you believe that suspend in any form is a solution to the rogue app problem ... whether it's implemented in Java or C is an ancillary issue. 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: Pavel Machek on 26 May 2010 13:50 Hi! > > > > 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. > > > > > > OK, so I believe you have an android phone ... it already implements > > > this model ... specifically what are the problems on that platform this > > > causes? > > > > I do not have one, nor have I ever written an application for it (nor > > will I likely ever do that, since I detest Java), but I would expect an > > application to run when its runnable. > > OK, so I've got one ... tell me what I should see and I'll try to > reproduce. Umm... try to boot ordinary distro and see how it copes with opportunistic suspend? I do have android here, and of course it work well with custom userland. Question is: can common distro be reasonably modified to work with suspend blockers, in a way that's backward compatible? 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: Thomas Gleixner on 26 May 2010 14:00 On Wed, 26 May 2010, James Bottomley wrote: > On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote: > > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote: > > > 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. > > You mean this one: > > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html > > ? > > > It was apparently hidden on some funky list. > > Sending a PM pull request to the PM list doesn't really strike me as the > height of obfuscation. Plus almost everyone who objected was on the cc > list. > > > Hiding pull requests is bad enough, but hiding pull requests for > > contended features is just plain wrong. > > I don't think it's a conspiracy ... just standard operating procedure > for this subsystem. I do think cc'ing lkml is good practise (having > been yelled at for not doing that in the past) but it's certainly not > universal practise. At least it would be good style for a topic which is 1) contended like this one 2) pushing an intrusive feature last minute which has been merged into the pm tree barely two days ago. Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone. Thanks, tglx -- 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: Pekka Enberg on 26 May 2010 14:10
On Wed, May 26, 2010 at 8:40 PM, James Bottomley <James.Bottomley(a)suse.de> wrote: >> On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote: >> >> Yup, I don't quite get Arve's argument either. C code can interact >> >> with Java code (and vice versa) just fine in userspace. >> >> On Wed, May 26, 2010 at 7:18 PM, James Bottomley >> <James.Bottomley(a)suse.de> wrote: >> > This is an incorrect statement. �It's possible for java to call C via >> > the JNI, even though there are quite a few gotchas that mean not just >> > *any* C code can do it (been there, tripped over some of them, although >> > they were all ultimately ironed out). �It's very difficult for C to call >> > directly into Java without being specially coded because it involves >> > creating and managing a JVM (so in general, arbitrary C code can't do >> > this). �The usual way we do C -> Java is process to process via some >> > intermediary like RPC or Corba or SOAP (or even JSON) ... which gets >> > very messy for a mobile device. >> >> Incorrect statement how exactly? A JVM can do mmap(), for example, >> just fine through FileChannel.map() so there's no need for >> heavy-weight RPC. > > Incorrect in that an arbitrary C application can't link to a java API. Dunno what you mean by "arbitrary" C application but yes, I do agree that using JNI is somewhat cumbersome. Not sure if that's relevant, though, as it can all be hidden in the framework APIs. > mmap and some other messaging (like signals) is just another form of > IPC ... the list I gave wasn't exhaustive. The protocols you mentioned are meant for RPC (as in remote) and messaging, not for IPC which I'm assume is needed for the suspend manager process Peter is talking about. >> �Furthermore, the whole discussion is moot anyway as >> Android runs Dalvik which can be hacked to support whatever >> communication mechanism is the best choice here. >> >> So can we drop the whole "we need to do it in kernel because Java is >> hard" nonsense and concentrate on real issues? > > I've lost you. �This argument seems to hinge on whether or not you > believe that suspend in any form is a solution to the rogue app > problem ... whether it's implemented in Java or C is an ancillary issue. I'm responding to the original argument from Arve that C programs can't use the existing suspend manager because it's written in Java. -- 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/ |