[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: mark gross on 4 Jun 2010 23:30 On Thu, Jun 03, 2010 at 04:30:49PM +0200, Florian Mickler wrote: > On Thu, 3 Jun 2010 06:24:49 -0700 > mark gross <640e9920(a)gmail.com> wrote: > > > On Thu, Jun 03, 2010 at 12:10:03AM -0700, Arve Hj�nnev�g wrote: > > > ok I'm not getting it. > > is this a fancy com-sci algorithm I should know about? > > > > --mgross > > I think you are at an advantage if you have studied fancy com-sci for > this? Here is an example: > > say you have 5 constraints: > qos1 with a value of 10 > qos2 with 5 > qos3 with 10 > qos4 with 11 > > Now, you hash that list by the qos-values: > > 11 ---- 10 ----- 5 > | | | > qos4 qos3 qos2 > | > qos1 > > > To compute the maximum you just walk the "----" list. > > To reduce qos4 from 11 to 5 you remove it from its "|" list and > prepend it to the corresponding "|" list. (4 Pointer adjustments + > searching the "-----" list for the right place to insert. > > result: > > 10 ---- 5 > | | > qos3 qos4 > | | > qos1 qos2 > > Cheers, Oh! ok, thats easy! Thanks!!! --mgross -- 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: Felipe Contreras on 5 Jun 2010 13:00 On Mon, May 31, 2010 at 8:55 AM, Igor Stoppa <igor.stoppa(a)nokia.com> wrote: > ext Felipe Contreras wrote: > >> I think this information can be obtained dynamically while the >> application is running, > > yes, that was the idea > >> and perhaps the limits can be stored. It would >> be pretty difficult for the applications to give this kind of >> information because there are so many variables. >> >> For example, an media player can tell you: this clip has 24 fps, but >> if the user is moving the time slider, the fps would increase and drop >> very rapidly, and how much depends at least on the container format >> and type of seek. >> > > I doubt that belongs to typical QoS. Maybe the target could be to be able to > decode a sequence of i-frames? I'm not sure what you mean. I-frames comes usually one per second, so if you only decode I-frames, your experience would be really bad. Moreover, you don't know beforehand when an I-frame is coming, only when it's there, and some clips can have only one I-frame at the beginning. >> A game or a telephony app could tell you "I need real-time priority" >> but so much as giving the details of latency and bandwidth? I find >> that very unlikely. >> > > from my gaming days the games were still evaluated in fps ... maybe i made > the wrong assumption? Yes, the more fps, the better, but you calculate that by counting the amount of frames rendered over a period of time; you know the fps *after* the fact. > A telephony app should still be able to tell if it's dropping audio frames. Yes, which could be unrelated to PM, like bad network conditions, but yeah, it should also be able to tell if the problem is with the application itself (audio decoder too slow). > In all cases there should be some device independent limit - like: what is > the sort of degradation that is considered acceptable by the typical user? It is easy to tell after the PM actions have been made, as in "wait! I'm not able to perform gimme more power!". But I don't see how that could be done _before_ the PM actions are done. From all the QoS proposals I have seen here, and considering that some people said that suspend blockers could be a specific case of QOS, I don't think people have been considering QoS as something to state _after_. > Tuning might be offered, but at least this should set some sane set of > defaults. Huh? Defaults in what units, based on what, and when and how to update? Cheers. -- Felipe Contreras -- 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: Felipe Contreras on 5 Jun 2010 13:10 On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <florian(a)mickler.org> wrote: > On Mon, 31 May 2010 22:12:19 +0200 > Florian Mickler <florian(a)mickler.org> wrote: >> If I have a simple shell script then I don't wanna jump through >> hoops just to please your fragile kernel. > > Also why should that code on one device kill my uptime and on the > other machine (my wall-plugged desktop) work just well? That doesn't > sound right. Sounds perfectly right to me; one code runs perfectly fine on one machine, and on the other doesn't even compile. Well, sure, it wasn't written with that use-case in mind. > Clearly opportunistic suspend is a workaround for battery-driven devices > and no general solution. But it is not specific to android. At least > not inherently. It could be useful for any embedded or mobile device > where you can clearly distinguish important functions from convenience > functions. Yes, it could, but why go for the hacky solution when we know how to achieve the ideal one? > I really can't understand the whole _fundamental_ opposition to this > design choice. Nobody is using it, except Android. Nobody will use it, except Android. I have seen recent proposals that don't require changing the whole user-space. That might actually be used by other players. -- Felipe Contreras -- 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: Felipe Contreras on 5 Jun 2010 13:20 On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki <rjw(a)sisk.pl> wrote: > Do you realistically think that by hurting the _user_ you will make the > _developer_ write better code? No, really. As an application writer, if my users complain that their battery is being drained (as it happened), they stop using it, and other people see there are problems, so they stop using it, if people get angry about it they will vote it down. New users will see it has low score; they will not install it. That's a network effect. Having users is the quintessential reason people write code. > If the user likes the app very much (or depends on it or whatever makes him > use it), he will rather switch the platform to one that allows him to run that > app without _visible_ problems than complain to the developer, because _the_ > _user_ _doesn't_ _realize_ that the app is broken. From the user's > perspective, the platform that has problems with the app is broken, because > the app apparently runs without problems on concurrent platforms. Yeah, right. I don't think anybody has every bought an iPhone because of Tweetie. People care how the applications run on their phones, not how their phone's platform runs their favorite application, in fact, most probably it became their favorite application because it was running great on their phone, and they wouldn't expect it to run on phones with other platforms. Either applications run on S60, iPhone OS, Android, or Maemo, but not in a combination of those. And if their certain app that runs on multiple platforms, and the user actually knows that (probably a geek), then he knows he can't expect it to work exactly the same. > The whole "no reason to tolerate broken apps" midset is simply misguided IMO, > because it's based on unrealistic assumptions. That's because in general users > only need the platform for running apps they like (or need or whatever). If > they can't run apps they like on a given platform, or it is too painful to them > to run their apps on it, they will rather switch to another platform than stop > using the apps. You seriously think people switch high-end phones just to run their favorite apps? It's much cheaper to switch apps, and that's what users do. -- Felipe Contreras -- 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: Felipe Contreras on 5 Jun 2010 13:40
On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra <peterz(a)infradead.org> wrote: > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote: >> On Thu, 03 Jun 2010 09:40:02 +0200 >> Peter Zijlstra <peterz(a)infradead.org> wrote: >> >> > Same for firefox, you can teach it to not render animated gifs and run >> > javascript for invisible tabs, and once the screen-saver kicks in, >> > nothing is visible (and with X telling apps their window is visible or >> > not it knows), so it should go idle all of its own. >> > >> > Fix the friggin apps, don't kludge with freezing. >> >> Of course programs should be as smart as possible. But that is an >> orthogonal problem. >> >> Suppose firefox were fixed. It still needs to fetch my rss feeds every >> minute, because I'm sad if it doesn't. It just can't be fixed at the >> application level. > > Sure it can, why would it need to fetch RSS feeds when the screen is off > and nobody could possible see the result? So you can stop the timer when > you know the window isn't visible or alternatively when the screensaver > is active, I think most desktops have notification of that as well. Exactly, and that's what applications in the N900 do. For this to work reliably, you need these notifications (network disconnected, screen off) to be easily accessible, and even transparent to the application writer. I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs. When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever). We end up in exactly the same situation. -- Felipe Contreras -- 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/ |