On Wed, 19 May 2010 09:59:34 +0300
Felipe Balbi felipe.ba...@nokia.com 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
On Thu, 20 May 2010 11:57:40 +0300
Felipe Balbi m...@felipebalbi.com 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 user
On Wed, 26 May 2010 11:45:06 +0200
Peter Zijlstra pet...@infradead.org 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 pet...@infradead.org
wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of
On Wed, 26 May 2010 12:08:04 +0200
Peter Zijlstra pet...@infradead.org 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
system
On Wed, 26 May 2010 14:01:49 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org 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
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com 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 hours. Which
On Wed, 26 May 2010 15:35:32 +0300
Felipe Balbi felipe.ba...@nokia.com 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 distribution
channels
On Wed, 26 May 2010 14:41:29 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler
On Wed, 26 May 2010 14:55:31 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org 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
On Wed, 26 May 2010 15:07:27 +0200
Peter Zijlstra pet...@infradead.org 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
screaming.
We
On Wed, 26 May 2010 14:19:42 +0100
Alan Cox a...@lxorguk.ukuu.org.uk 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.
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org 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
Opt
On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm
On Wed, 26 May 2010 17:47:35 +0200
Florian Mickler flor...@mickler.org wrote:
On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org
On Wed, 26 May 2010 19:02:04 +0100
Alan Cox a...@lxorguk.ukuu.org.uk 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.
On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote:
Your approach definitely sounds better than the current solution.
What about mapping suspend blocker functionality later on, when
On Wed, 26 May 2010 23:09:43 +0100
Alan Cox a...@lxorguk.ukuu.org.uk 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
On Wed, 26 May 2010 10:38:50 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu 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
suspend framework
On Thu, 27 May 2010 16:10:54 +0100
Alan Cox a...@lxorguk.ukuu.org.uk 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
On Thu, 27 May 2010 18:45:25 +0200 (CEST)
Thomas Gleixner t...@linutronix.de 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
On Thu, 27 May 2010 19:25:27 +0200
Peter Zijlstra pet...@infradead.org 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 t...@linutronix.de wrote:
The whole notion of treating suspend to RAM any different than
On Thu, 27 May 2010 21:55:26 -0700
Brian Swetland swetl...@google.com wrote:
On Thu, May 27, 2010 at 3:55 PM, Alan Cox a...@lxorguk.ukuu.org.uk 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
On Thu, 27 May 2010 22:09:37 -0400
Ben Gamari bgamari.f...@gmail.com wrote:
On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler flor...@mickler.org
wrote:
Because he is using a robust kernel that provides suspend blockers and
is preventing the vampire from sucking power?
Suspend
On Thu, 27 May 2010 15:35:18 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Thu, 27 May 2010, Florian Mickler wrote:
On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org
wrote
On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner t...@linutronix.de 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.
On Fri, 28 May 2010 02:18:06 -0700
Arve Hjønnevåg a...@android.com 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
On Fri, 28 May 2010 04:35:34 -0700
Arve Hjønnevåg a...@android.com wrote:
2010/5/28 Florian Mickler flor...@mickler.org:
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.
To me
On Fri, 28 May 2010 16:59:54 +0200
Peter Zijlstra pet...@infradead.org 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
On Sat, 29 May 2010 02:42:35 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa igor.sto...@nokia.com wrote:
ext Brian Swetland wrote:
How is it flawed? Serious question.
I would avoid repeating all the good arguments given so far, but
On Sat, 29 May 2010 10:28:19 +0200
Florian Mickler flor...@mickler.org wrote:
On Sat, 29 May 2010 02:42:35 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa igor.sto...@nokia.com wrote:
ext Brian Swetland wrote:
How is it flawed
On Sat, 29 May 2010 20:12:14 +0200
Peter Zijlstra pet...@infradead.org 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
On Mon, 31 May 2010 22:12:19 +0200
Florian Mickler flor...@mickler.org wrote:
On Sat, 29 May 2010 20:12:14 +0200
Peter Zijlstra pet...@infradead.org 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
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:
On Tue, 1 Jun 2010 12:20:12 +1000
Neil Brown ne...@suse.de wrote:
On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
Thomas Gleixner t...@linutronix.de 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
On Wed, 2 Jun 2010 18:06:14 +1000
Neil Brown ne...@suse.de 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
On Wed, 2 Jun 2010 21:02:24 +1000
Neil Brown ne...@suse.de 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
On Wed, 02 Jun 2010 10:05:11 -0500
James Bottomley james.bottom...@suse.de 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
On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
2010/6/2 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
No I want you to stop confusing low power idle
On Wed, 02 Jun 2010 15:41:11 -0500
James Bottomley james.bottom...@suse.de wrote:
On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
On Wed, 02 Jun 2010 10:05:11 -0500
James Bottomley james.bottom...@suse.de wrote:
On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote
On Wed, 2 Jun 2010 16:32:44 -0700
Dmitry Torokhov dmitry.torok...@gmail.com 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 ne...@suse.de wrote:
And this decision (to block suspend) really needs to be made
On Thu, 03 Jun 2010 09:40:02 +0200
Peter Zijlstra pet...@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
On Thu, 03 Jun 2010 08:24:31 -0500
James Bottomley james.bottom...@suse.de 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.
On Fri, 04 Jun 2010 09:24:06 -0500
James Bottomley james.bottom...@suse.de 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
On Thu, 03 Jun 2010 17:28:01 +0200
Peter Zijlstra pet...@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 pet...@infradead.org wrote:
Same for firefox, you can teach it to not render animated gifs and run
On Sat, 5 Jun 2010 20:16:33 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki r...@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
On Sat, 5 Jun 2010 20:30:40 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra pet...@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 pet...@infradead.org
On Sat, 5 Jun 2010 20:44:24 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
2010/6/2 Arve Hjønnevåg a...@android.com:
2010/6/2 Peter Zijlstra pet...@infradead.org:
(and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
fixing it, get over it already).
I don't
On Thu, 3 Jun 2010 19:16:55 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org 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
On Sat, 5 Jun 2010 23:06:03 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler flor...@mickler.org wrote:
On Sat, 5 Jun 2010 20:30:40 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
I don't think the suspend blockers solve
On Sat, 5 Jun 2010 23:26:27 +0300
Felipe Contreras felipe.contre...@gmail.com 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
On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
Thomas Gleixner t...@linutronix.de 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
On Sat, 5 Jun 2010 22:56:45 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler flor...@mickler.org wrote:
On Sat, 5 Jun 2010 20:16:33 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
New users will see it has low score
On Sun, 6 Jun 2010 12:00:47 +0200
Vitaly Wool vitalyw...@gmail.com 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
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 da...@lang.hm:
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
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 vitalyw...@gmail.com wrote:
2010/6/6 da...@lang.hm:
as an example (taken from this thread).
system A needs to wake up to get
On Sun, 6 Jun 2010 19:21:49 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
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
On Sun, 6 Jun 2010 20:01:56 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu 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
On Mon, 7 Jun 2010 20:05:56 -0700
Arve Hjønnevåg a...@android.com 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
58 matches
Mail list logo
