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 14:20 On Wed, 2010-05-26 at 19:42 +0200, Pavel Machek wrote: > 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? That's not really going to help, is it? The issue I was curious are what are the bad things that result from interfering with the regular scheduling of processes ... because undeniably suspend (whether opportunistic or ordinary) does produce this interference. I could boot debian on an android and have it suspend ... that's still not going to answer my question. > 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? You mean how an app could run if it was compiled with suspend blockers but the platform doesn't support it? That's a simple runtime switch in the library surely? 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 14:30 On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote: > 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. Don't disagree ... I was just explaining how it could happen while not being a conspiracy. > Darn, _we_ have to deal with that forever as it sets a crappy user > space ABI in stone. I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it. Even on those platforms that do support it, we can translate most of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over. 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: Florian Mickler on 26 May 2010 15:20 On Wed, 26 May 2010 19:28:24 +0200 Pavel Machek <pavel(a)ucw.cz> wrote: > Besides that it is not linux system at all? I believe the kernel to be a layer between userspace and hardware. What business is it to the kernel if it runs whatever android uses as init process or /bin/bash, sys-v-init or systemd? There is this thing called choice. > > Yes, with custom userspace it works extremely nicely. > > Had anyone even tried running oportunistic suspend on normal desktop? > Pavel I don't think this is a valid concern. Just because current linux/gnu systems don't implement the userspace part of this interface doesn't mean it is useless or broken. Cheers, Flo -- Just because I argue an issue, doesn't mean I agree with either side of it. -- 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 16:10 On Wed, 2010-05-26 at 14:50 -0400, Valdis.Kletnieks(a)vt.edu wrote: > On Wed, 26 May 2010 13:23:00 CDT, James Bottomley said: > > On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote: > > > Darn, _we_ have to deal with that forever as it sets a crappy user > > > space ABI in stone. > > > > I really don't see how it is ... the ABI comes with a switch that allows > > it to be disabled, so only platforms wishing to use it have to support > > it. Even on those platforms that do support it, we can translate most > > of it into pm QoS stuff and if one day someone solves the rogue app > > problem, we can migrate over. > > And yet, the OSS drivers are *still* in-tree, even though similar arguments > apply to an OSS->ALSA migration. And there's a bunch of other stuff in > Documentation/feature-removal-schedule.txt in a similar situation. On the other hand APM, which is what all laptops used to use to suspend is gone from the x86 kernel today ... replaced by ACPI or other platform mechanisms, so it is at least possible. 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: Linus Walleij on 26 May 2010 17:00
2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > On Wed, 2010-05-26 at 03:17 -0700, Arve Hj�nnev�g wrote: >> > With a single suspend manager process that manages the suspend state you >> > can achieve the same goal. >> > >> >> Yes we don't need the /dev interface, but it is useful. Without it any >> program that needs to block suspend has to make a blocking ipc call >> into the suspend manager process. Android already does this for java >> code, but system processes written in C block suspend directly with >> the kernel since they cannot use the java APIs. > > So provide a C interface to it as well? > > Surely you can have the java thing have a unix socket or something a C > app can talk to. That shouldn't be hard at all. > > Or make the suspend manager a C proglet and provide a JNI interface, or > whatever. Android already has D-Bus: http://android.git.kernel.org/?p=platform/external/dbus.git;a=summary Which has Java bindings: http://dbus.freedesktop.org/doc/dbus-java/ D-Bus can be from C to send messages to the Java daemon. So why not use that if this seems to be a problem. It even brings serialized typing and all that funny stuff. Yours, Linus Walleij -- 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/ |