[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: tytso on 28 May 2010 09:40 On Fri, May 28, 2010 at 04:32:15PM +0300, Igor Stoppa wrote: > > What I consider plain wrong i to claim that since there are this > many units out, some code should be merged. > A company needs to cut corners sometimes when making a product but > this should not affect upstream code. Linus will disagree with you there. Linus *has* merged code on the basis that it is shipping in distributions, regardless of the fact that some developers objected to it. Sometimes "perfect" should not be the enemy of "good enough" shipping code. For example, I used to point out that we shipped PCMCIA code in mainline that had a 10% chance of crashing the system if you ejected the card. NetBSD was proud to say that their code was so iron-clad and well designed that it always did the right thing, even if you ejected while it was busily passing network traffic. Unfortunately, NetBSD had working PCMCIA support 3 years later than Linux. So it used to be that we were the technical pragmatists (and Linus fortunately, still very much is the pragmatists, while others were the hard-line perfectionists. It seems to me we've started getting some of the NetBSD attitude infecting LKML, and IMHO, that's unfortunate. We've rewritten our networking stack, 3 or 4 times, depending on how you count. And sometimes shipping in products counts for a lot. It doesn't count for everything, and it isn't a get-out-of-jail card, for sure. But if it's a hard problem, and we have something that's good enough, maybe the right call is to merge it now, and we'll rework things to make something better and more general later. Ultimately that's a call only Linus can make. If everyone agrees we're making progress, and we can let this 100+ mail thread keep going. But if anyone feels that we are spinning endlessly without making forward progress (which is after all the same criteria the OOM killer uses, no? :-), people should remember that sometimes Linus *has* ended arguments that have gone on too long by making a "merge or kill" decision. - Ted -- 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: Alan Cox on 28 May 2010 09:50 On Fri, 28 May 2010 12:41:23 +0100 Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote: > > > The other vendors appear to be managing nicely without magic blockers. I > > conjecture therefore there are other solutions. > > Actually, no. A badly behaved application will kill the N900's battery > life. Nobody else has "managed nicely" - they've just made life harder > for application developers and users, which may have something to do > with the relative levels of market adoption of Maemo and Android. I'm > not aware of any form of resource management framework in MeeGo either, > so as far as I know it'll have exactly the same problem. Maemo has battery management applications. Right now they show you what is going on but haven't gone to a pop-up 'XYZ is eating all your battery' kill it behaviour. The information is there. If my phone eventually becomes a 1GB RAM PC class system I will be running PC class apps on it and I will be migrating virtual machines to and from my phone which have no idea about the device properties of each device they migrate to and from. Be that as it may the question of how you manage a naughty app is a good one. Historically we've managed them for network abuse, memory abuse, cpu use abuse, access rights, but not yet power. Whether that looks like setrlimit(pid, LIMIT_CHARGE, 150mWH); or setrlimit(pid, LIMIT_POWER, 150mW); or something else is the question. I rather like the above but I don't see how to implement them nicely at the moment. Alan -- 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: Igor Stoppa on 28 May 2010 10:00 ext Brian Swetland wrote: > How is it flawed? Serious question. > I would avoid repeating all the good arguments given so far, but to make it short: * I believe runtime PM is a much better starting point (at least for the type of HW targeted at mobile devices) because it mimics an always-on system toward userspace, which requires less disruption in the way apps are designed * QoS is closer to the apps pov: fps if it is a media player or a game, transfer speed if it is a file manager, bandwidth if it is a network app, etc The app is required to express its opinion by using a format that it understands better and is less system dependent. Actually the kernel should only be concerned with 2 parameters at most for any given operation: latency and bandwidth/throughput * Some form of resource management is needed as trust mechanism to discriminate "trusted" vs untrusted apps that can give reliable info (but in your case you should give trust to whom prevents the suspend) * Most of this could be done in userspace with the kernel merely providing the means to enforce the decisions taken by the userspace manager. * The kernel wouldn't even have to try to outsmart the "evil application writer" igor -- 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: Matthew Garrett on 28 May 2010 10:10 On Fri, May 28, 2010 at 02:55:26PM +0100, Alan Cox wrote: > The following cannot occur on my laptop for simple idling > > Alarm > Suspend > > because the Alarm resets the suspend timer when it is delivered. Userspace is about to write to /sys/power/state when it gets scheduled. Alarm delivery occurs at that instant. Kernel has no idea that it's about to go to sleep, so the driver handles things appropriately and clears the hardware state. Userspace gets scheduled, writes and the system suspends. The problem is that having userspace decidie to initiate a suspend and then actually initiate a suspend isn't an atomic operation. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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: Matthew Garrett on 28 May 2010 10:10
On Fri, May 28, 2010 at 02:54:20PM +0100, Alan Cox wrote: > I am not convinced at this point. If the app gets put into the important > group by the driver then you don't need to poke a policy manager. Ok, I think I've misunderstood you. You're actually saying that only applications that are trusted to behave well are allowed to receive wakeup events? Yes, that makes implementation significantly easier. If that maps reasonably well onto the existing Android application space, it may even be an acceptable compromise. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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/ |