On Mon, 7 Jun 2010 20:05:56 -0700
Arve Hjønnevåg wrote:
Hi,
>
> If you read an event that occurred after you blocked the task
> freezing, then tasks will never get frozen again (until more events
> occur). I think my original description was less confusing, but it
> seems you got completely dist
On Sun, 6 Jun 2010 20:01:56 -0400 (EDT)
Alan Stern wrote:
> And since Android can reach essentially the same low-power
> state from idle as from suspend, it appears that they really don't need
> any kernel changes at all.
Well, perhaps a hint to the scheduler to fall through as fast as
possible
On Sun, 6 Jun 2010 19:21:49 +0200
Vitaly Wool wrote:
> 2010/6/6 Matthew Garrett :
>
> > Suspend blocks prevent system suspend, not any per-device suspend.
>
> Can you suspend a device which is holding a wake lock?
>
> ~Vitaly
If you look at the suspend blocker patchset, you'll see that the on
On Sun, 6 Jun 2010 04:14:09 -0700 (PDT)
da...@lang.hm wrote:
> On Sun, 6 Jun 2010, Florian Mickler wrote:
>
> > On Sun, 6 Jun 2010 12:19:08 +0200
> > Vitaly Wool wrote:
> >
> >> 2010/6/6 :
> >>
> >>> as an example (taken from this thread).
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool wrote:
> 2010/6/6 :
>
> > as an example (taken from this thread).
> >
> > system A needs to wake up to get a battery reading, store it and go back to
> > sleep, It does so every 10 seconds. But when it does so it only runs the one
> > process and th
On Sun, 6 Jun 2010 12:00:47 +0200
Vitaly Wool wrote:
> Even worse, the suspend wakelock will keep the
> whole kernel active, as opposed to powering off unused devices
> separately as it's done in runtime PM.
That is not true. While the kernel is not suspended it does
runtime pm.
> > Users do
On Sat, 5 Jun 2010 22:56:45 +0300
Felipe Contreras wrote:
> On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler wrote:
> > On Sat, 5 Jun 2010 20:16:33 +0300
> > Felipe Contreras wrote:
> >> New users will see it has low score; they will not install it. That
On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
Thomas Gleixner wrote:
> Stop that advertising campaing already.
Stop advertising that there is no problem.
>
> No thanks,
>
> tglx
Cheers,
Flo
(Sorry, crossfire. Caused
by you answering in the wrong subthread. I know that you are
engineering
On Sat, 5 Jun 2010 23:26:27 +0300
Felipe Contreras wrote:
> Supposing there's a perfect usage of suspend blockers from user-space
> on current x86 platforms (in theory Android would have that), is the
> benefit that big to consider this a strong argument in favor of
> suspend blockers? Considerin
On Sat, 5 Jun 2010 23:06:03 +0300
Felipe Contreras wrote:
> On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler wrote:
> > On Sat, 5 Jun 2010 20:30:40 +0300
> > Felipe Contreras wrote:
> >> I don't think the suspend blockers solve much. A bad application will
On Thu, 3 Jun 2010 19:16:55 -0700 (PDT)
Linus Torvalds wrote:
> The thing is, unless there is some _really_ deep other reason to do
> something like this, I still think it's total overdesign to push any
> knowledge/choices like this into the scheduler. I'd rather keep things way
> more indepen
On Sat, 5 Jun 2010 20:44:24 +0300
Felipe Contreras wrote:
> 2010/6/2 Arve Hjønnevåg :
> > 2010/6/2 Peter Zijlstra :
> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
> >> fixing it, get over it already).
> >>
> >
> > I don't think it is realistic to drop support for all
On Sat, 5 Jun 2010 20:30:40 +0300
Felipe Contreras wrote:
> On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra wrote:
> > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> >> On Thu, 03 Jun 2010 09:40:02 +0200
> >> Peter Zijlstra wrote:
> >>
> >&
On Sat, 5 Jun 2010 20:16:33 +0300
Felipe Contreras wrote:
> On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki 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 th
On Thu, 03 Jun 2010 17:28:01 +0200
Peter Zijlstra wrote:
> On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> > On Thu, 03 Jun 2010 09:40:02 +0200
> > Peter Zijlstra wrote:
> >
> > > Same for firefox, you can teach it to not render animated gifs and run
On Fri, 04 Jun 2010 09:24:06 -0500
James Bottomley wrote:
> On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote:
> > Anyway, i'm not pessimistic at all: _some_ sort of scheme appears to be
> > crystalising out today. Everyone seems to agree now that the main usecases
> > are
> > indeed useful
On Thu, 03 Jun 2010 08:24:31 -0500
James Bottomley wrote:
> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > > [mtg: ] This has been a pain point for the PM_QOS implementation. They
> > > change the constrain back and forth at the transaction level of the i2c
> > > driver. The pm_qos co
On Thu, 03 Jun 2010 09:40:02 +0200
Peter Zijlstra 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 sh
On Wed, 2 Jun 2010 16:32:44 -0700
Dmitry Torokhov wrote:
> On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
> > On Wed, 2 Jun 2010 21:02:24 +1000
> > Neil Brown wrote:
> > >
> > > And this decision (to block suspend) really needs to be made i
On Wed, 02 Jun 2010 15:41:11 -0500
James Bottomley wrote:
> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
> > On Wed, 02 Jun 2010 10:05:11 -0500
> > James Bottomley wrote:
> >
> > > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> >
On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra wrote:
> On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
> > 2010/6/2 Peter Zijlstra :
> > > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> > >> No I want you to stop confusing low power idle modes with suspend.
> > >
> > > I
On Wed, 02 Jun 2010 10:05:11 -0500
James Bottomley wrote:
> On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> > No, they have to be two separate constraints, otherwise a constraint
> > to block suspend would override a constraint to block a low power idle
> > mode or the other way around
On Wed, 2 Jun 2010 21:02:24 +1000
Neil Brown wrote:
>
> And this decision (to block suspend) really needs to be made in the driver,
> not in userspace?
Well, it fits. The requirement is a direct consequence of the intimate
knowledge the driver has about the driven devices.
Or if you get in an u
On Wed, 2 Jun 2010 18:06:14 +1000
Neil Brown wrote:
> I cannot imagine why it would take multiple seconds to scan a keypad.
> Can you explain that?
>
> Do you mean while keys are held pressed? Maybe you don't get a wake-up event
> on key-release? In that case your user-space daemon could block
On Tue, 1 Jun 2010 12:20:12 +1000
Neil Brown wrote:
> On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
> Thomas Gleixner wrote:
> > If "suspend" is another deep idle state and the hardware is sane,
> > there is no race at all - assumed that the driver/platform developer
> > got it right. It's not rocke
Hi, again!
My two mails were probably a bit pointless and not helping to
find a solution.
There are notable and useful approaches mentioned by Peter to the
mitigation problem. It's just that it's not the one and only way to
think about this.
Just rants,
Flo
--
To unsubscribe from this list: se
On Mon, 31 May 2010 22:12:19 +0200
Florian Mickler wrote:
> On Sat, 29 May 2010 20:12:14 +0200
> Peter Zijlstra wrote:
> >
> > Why would you try to let buggy apps work as intended instead of break
> > them as hard as possible? Such policy promotes crappy code since peo
On Sat, 29 May 2010 20:12:14 +0200
Peter Zijlstra wrote:
> On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > > Correct, I strongly oppose using suspend. Not running runnable tasks is
> > > not a sane solution.
> >
> > Look, this is getting into the realms of a pointless semantic quib
On Sat, 29 May 2010 10:28:19 +0200
Florian Mickler wrote:
> On Sat, 29 May 2010 02:42:35 +0300
> Felipe Contreras wrote:
>
> > On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa wrote:
> > > ext Brian Swetland wrote:
> > >> How is it flawed? Serious question.
On Sat, 29 May 2010 02:42:35 +0300
Felipe Contreras wrote:
> On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa wrote:
> > 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 beli
On Fri, 28 May 2010 16:59:54 +0200
Peter Zijlstra wrote:
> So lets look at the problem, we want to be frugal with power, this means
> that the system as a whole should strive to do nothing. And we want to
> enforce this as strict as possible.
An interesting thought might be to add the costs of s
On Fri, 28 May 2010 04:35:34 -0700
Arve Hjønnevåg wrote:
> 2010/5/28 Florian Mickler :
> > It sounds like it could save some duplication of effort to integrate
> > suspend into the idle-framework. "Purpose-fulness" could be just
> > another measure of "idle
On Fri, 28 May 2010 02:18:06 -0700
Arve Hjønnevåg wrote:
> > IMO, the whole concept is defining 2 modes of operation:
> >
> > 1. user interacts with the device (at least one suspend block active)
> > 2. user doesn't interact with the device (zero suspend block active)
>
> That is a somewhat odd
On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
>
> > On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
> >
> > > Oh no. They paper over a short coming. If there is a pending event,
> > > the kernel knows that. It jus
On Thu, 27 May 2010 15:35:18 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 27 May 2010, Florian Mickler wrote:
>
> > On Wed, 26 May 2010 22:03:37 +0200
> > Vitaly Wool wrote:
> >
> > > On Wed, May 26, 2010 at 9:56 PM, Florian Mickler
> > > wrot
On Thu, 27 May 2010 22:09:37 -0400
Ben Gamari wrote:
> On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler
> wrote:
> > Because he is using a robust kernel that provides suspend blockers and
> > is preventing the vampire from sucking power?
> >
> Suspend blo
On Thu, 27 May 2010 21:55:26 -0700
Brian Swetland wrote:
> On Thu, May 27, 2010 at 3:55 PM, Alan Cox wrote:
> >
> > This started because the Android people came to a meeting that was put
> > together of various folks to try and sort of the big blockage in getting
> > Android and Linux kernels ba
On Thu, 27 May 2010 19:25:27 +0200
Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote:
> > On Thu, 27 May 2010 18:45:25 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> > > The whole notion of treating suspend to RAM any different than
On Thu, 27 May 2010 18:45:25 +0200 (CEST)
Thomas Gleixner wrote:
> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut
On Thu, 27 May 2010 16:10:54 +0100
Alan Cox wrote:
> The reality is you need a sane, generic, race free way to express your
> requirements (eg for hard RT) and ditto for constraining the expression
> (for 'crapplications')
And the thing is, even a well written app can be a 'crapplication'
depend
On Wed, 26 May 2010 10:38:50 -0400 (EDT)
Alan Stern wrote:
> On Wed, 26 May 2010, Florian Mickler wrote:
>
> > I don't think that the in-kernel suspend block is a bad idea.
> >
> > You could probably use the suspend-blockers unconditionally in the
> >
On Wed, 26 May 2010 23:09:43 +0100
Alan Cox wrote:
> We now have suggestions how to do the job properly so the right thing is
> probably to go and explore those suggestions not merge crap.
>
> Merging crap won't help anyway. The rest of the kernel community can
> still simply stonewall those int
On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool wrote:
> On Wed, May 26, 2010 at 9:56 PM, Florian Mickler wrote:
>
> > Your approach definitely sounds better than the current solution.
> > What about mapping suspend blocker functionality later on, when this
> > interfac
On Wed, 26 May 2010 19:02:04 +0100
Alan Cox wrote:
> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
>
> Even if you believe
On Wed, 26 May 2010 19:22:16 +0200 (CEST)
Thomas Gleixner wrote:
> Florian,
>
> On Wed, 26 May 2010, Florian Mickler wrote:
> >
> > On the other hand, applications can say, they don't need that much
> > power and userspace guaranties and not take a suspend blo
On Wed, 26 May 2010 17:47:35 +0200
Florian Mickler wrote:
> On Wed, 26 May 2010 17:45:00 +0200
> Peter Zijlstra wrote:
>
> > On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > > On Wed, 26 May 2010 17:15:47 +0200
> > > Peter Zijlstra wrote:
> &
On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 17:15:47 +0200
> > Peter Zijlstra wrote:
> >
> > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > >
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > I'm not saying that your argument is not valid. But why don't you look
> > at suspend blockers as a contract between userspace and kernelspace? An
On Wed, 26 May 2010 14:16:12 +0100
Alan Cox wrote:
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> >
> > And if you have two kernels, one with which your device is dead after 1
> > hour
On Wed, 26 May 2010 14:19:42 +0100
Alan Cox wrote:
> > This is a _big_ plus for attracting 3rd party programs. (And of course
> > the thing you don't like).
>
> You would do better to concentrate on technical issues that the
> assignment of malicious intent to other parties.
>
> Alan
This wa
On Wed, 26 May 2010 15:07:27 +0200
Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> > The kernel can not win if it does not try to integrate any use of it.
>
> If we'd integrate every patch that came to lkml, you'd run away
> screa
On Wed, 26 May 2010 14:55:31 +0200
Vitaly Wool wrote:
> On Wed, May 26, 2010 at 2:24 PM, Florian Mickler wrote:
>
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
On Wed, 26 May 2010 14:41:29 +0200
Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 15:29:32 +0300
> > Felipe Balbi wrote:
> >
> > > hi,
> > >
> > > On Wed, May 26, 2010 at 02:24:30PM +02
On Wed, 26 May 2010 15:35:32 +0300
Felipe Balbi wrote:
> Hi,
>
> On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
> >But then someone at the user side has to know what he is doing.
> >
> >I fear, if you target mass market without central distributi
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi wrote:
> hi,
>
> On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> >And if you have two kernels, one with which your device is dead after 1
> >hour and one with which your device is dead after 10 hour
On Wed, 26 May 2010 14:01:49 +0200
Vitaly Wool wrote:
> On Wed, May 26, 2010 at 1:37 PM, Florian Mickler wrote:
>
> > This is not "protection". This is functioning properly in a real world
> > scenario. Why would the user change the kernel, if the device would be
&
On Wed, 26 May 2010 13:18:51 +0200
Vitaly Wool wrote:
> On Wed, May 26, 2010 at 12:02 PM, Florian Mickler wrote:
>
> >> So why again was this such a great scheme? Go fix your userspace to not
> >> not run when not needed.
> >
> > Hi Peter!
> >
>
On Wed, 26 May 2010 12:08:04 +0200
Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> &
On Wed, 26 May 2010 11:45:06 +0200
Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> > On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra
> > wrote:
> > > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > >> > This of course will lead to a scattering
On Thu, 20 May 2010 11:57:40 +0300
Felipe Balbi wrote:
> On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote:
> > But with that, you still shift the burden of exchanging that app with
> > an feature-equivalent non-broken version to the user.
> > which is not
On Wed, 19 May 2010 09:59:34 +0300
Felipe Balbi wrote:
> >The corollary is that real world systems have to operate in the face of
> >misbehaving hardware *and* software.
>
> I still think the kernel shouldn't deal with broken applications and we
> shouldn't try to fix them in kernel space. We
61 matches
Mail list logo
