On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > We were talking about PCs. Suspend-as-c-state is already implemented for
> > > OMAP.
> >
> > Ah, now we talk about PCs. And all of
On Thu, May 27, 2010 at 08:53:33PM +0100, Alan Cox wrote:
> On Thu, 27 May 2010 20:29:26 +0100
> Matthew Garrett wrote:
> > But wakeup events won't be delivered to STOPped processes, and there's
>
> Try the following
>
> catkill -STOP catpid
>
> echo "wombats are cool" > pi
On Thu, May 27, 2010 at 08:50:09PM +0100, Alan Cox wrote:
> So I guess if you are driving this rom user space (which I take it you
> are given you talk about housekeeping)
>
> foreach app we need to suspend
> kick app to suspend (signal)
> (policy) kick harder if
> We were talking about PCs. Suspend-as-c-state is already implemented for
> OMAP.
"You" were talking about PCs. Some of us are interested in the making
Linux do the right thing not adding platform specific hacks all over the
userspace of all the apps.
> > So the only thing you are imposing to
On Thu, 27 May 2010 19:23:03 +0100
Matthew Garrett wrote:
> On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Actually, the reverse - there's no terribly good way to make PCs work
> > > with scheduler-based suspend, but there's
On Thu, 27 May 2010 20:29:26 +0100
Matthew Garrett wrote:
> On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote:
>
> > The scheduler can happily do this, the power management will also
> > recognize STOPPED processes as no impediment to suspend.
>
> But wakeup events won't be delivered to
> Sigh. No. Forced suspend is a fact of life
'Fact of life' isn't a useful reasoning basis. It tells me nothing about
how you got to that pronouncement.
> Drivers should enable wakeups before they disable interrupts. So either
> the packet hits the IRQ handler and the driver takes a suspend bloc
On Thu, 27 May 2010, Alan Cox wrote:
> > Rather than continue going around in circles, let's agree that what the
> > Android people want is a new version of forced suspend -- not a
>
> I don't think this is true. I think that is the root of the problem.
Of course it's true. Just ask Arve -- h
On Thu, May 27, 2010 at 07:56:58PM +0100, Matthew Garrett wrote:
> Even if it's using poll, it could block purely on the display if X turns
> the screen off between poll() waking and the write being made.
That's what fcntl(fd, F_SETFL, O_NONBLOCK) is for.
--
To unsubscribe from this list: send t
On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote:
> The scheduler can happily do this, the power management will also
> recognize STOPPED processes as no impediment to suspend.
But wakeup events won't be delivered to STOPped processes, and there's
also the race of an application being in
On Thu, 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > > we still need to be able to enter suspend while the system isn't idle.
> > >
> > > _WHY_!?
> >
> > Because if I'm run
> Rather than continue going around in circles, let's agree that what the
> Android people want is a new version of forced suspend -- not a
I don't think this is true. I think that is the root of the problem.
I don't disagree with the user experience they are trying to create or
the fact someth
On Thu, 27 May 2010, Peter Zijlstra wrote:
> I still don't see how blocking applications will cause missed wakeups in
> anything but a buggy application at worst, and even those will
> eventually get the event when they unblock.
>
> What seems to be the confusion?
During forced suspend, applicat
> The problem is determining how to constrain it to go idle, where "idle"
> is defined as "Doesn't wake up until a wakeup event is received". It's
> acceptable for something to use as much CPU as it wants when the user is
> actively interacting with the device, but in most cases processes
> sho
On Thu, May 27, 2010 at 08:03:13PM +0100, Alan Cox wrote:
> > No, it's not. Forced suspend may be in response to hitting a key, but it
>
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idl
On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > We were talking about PCs. Suspend-as-c-state is already implemented for
> > OMAP.
>
> Ah, now we talk about PCs. And all of a sudden the problem of the
> unability of determining w
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
>
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
>
> If you want to support forced suspend for laptops and you want to avoid
> t
> > If one works so does the other.
>
> Not at all. The entire point of opportunistic suspend is that I don't
> care is currently in TASK_RUNNABLE or has a timer that's due to expire
> in 100msec - based on policy (through not having any held suspend
> blockers), I'll go to sleep. That's easily
On Thu, 27 May 2010 19:17:58 +0100
Matthew Garrett wrote:
> On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > > > On Thu, 2010-05-27 at 18:52 +0100
On Thu, 27 May 2010, Alan Cox wrote:
> > No, it's not. Forced suspend may be in response to hitting a key, but it
>
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.
>
> >
On Thu, May 27, 2010 at 07:48:40PM +0100, Alan Cox wrote:
> > The application is a network monitoring app that renders server state
> > via animated bouncing cows. The desired behaviour is that the
> > application will cease to be scheduled if the session becomes idle
> > (where idle is defined
> No, it's not. Forced suspend may be in response to hitting a key, but it
You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.
> may also be in response to a 30 minute timeout expir
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> > > If I get a WoL
> > > packet in the 0.5 of a second between userspace deciding to suspend and
> > > actually doing so,
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > ACPI provides no guarantees about what level of hardware functionality
> > > remains during S3. You don't have any useful ability to
Matthew Garrett writes:
> On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:
>
>> I'd prefer we avoided mixing them up. Everyone seems fairly happy with
>> the current operator ordered suspend behaviour I believe ?
>
> No. The current mechanism can lose wakeup events.
And the proposed sol
> Yes, there's no problem so far. The question is how you guarantee that
> the application has had the opportunity to handle the packet.
Because the application has said that it wants QoS guarantees. It wants
to know that if the events it can receive occur it will wake up within
the timescale.
S
On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
> So you need
>
> Userspace -> QoS guarantee expression, implied resource
> expression via device use. *NO* knowledge of
> device or platform in the application
I have a pile of use cases w
On Thu, May 27, 2010 at 08:22:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote:
>
> > It's blocked on the screen being turned off. It's supposed to be reading
> > a network packet. How does it ever get to reading the network packet?
>
> Its blocked bec
On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> > If I get a WoL
> > packet in the 0.5 of a second between userspace deciding to suspend and
> > actually doing so, the system shouldn't suspend.
>
> Please re-read Thom
On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > ACPI provides no guarantees about what level of hardware functionality
> > remains during S3. You don't have any useful ability to determine which
> > events will generate wakeups. A
On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > Actually, the reverse - there's no terribly good way to make PCs work
> > with scheduler-based suspend, but there's no reason why they wouldn't
> > work with the current opportunisti
On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote:
> It's blocked on the screen being turned off. It's supposed to be reading
> a network packet. How does it ever get to reading the network packet?
Its blocked because its a buggy app, who cares about misbehaviour in a
buggy app?
If it we
On Thu, May 27, 2010 at 07:17:16PM +0100, Alan Cox wrote:
> > Actually, the reverse - there's no terribly good way to make PCs work
> > with scheduler-based suspend, but there's no reason why they wouldn't
> > work with the current opportunistic suspend implementation.
>
> If one works so does t
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote:
> > > ACPI provides no guarantees about what level of hardware functionality
> > > remains during S3. You don't have any useful ability to determine which
> > > events will generate wakeups. A
On Thu, May 27, 2010 at 08:12:15PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > How long do you wait for applications to respond that they've stopped
> > drawing? What if the application is heavily in swap at the time?
>
> Very realistic scenario on a mobile pho
On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> If I get a WoL
> packet in the 0.5 of a second between userspace deciding to suspend and
> actually doing so, the system shouldn't suspend.
Please re-read Thomas' description of how a driver should do the state
transition.
So either w
On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > >
> > > > If that's what you're aiming
On Thu, May 27, 2010 at 08:05:39PM +0200, Thomas Gleixner wrote:
> You're just not getting it. If user space has consumed the event is
> not relevant at all.
>
> What's relevant is whether the app has processed the event and reacted
> accordingly. That's all that matters.
And how do you know tha
On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:
> I'd prefer we avoided mixing them up. Everyone seems fairly happy with
> the current operator ordered suspend behaviour I believe ?
No. The current mechanism can lose wakeup events.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubs
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> >
> > _WHY_!?
>
> Because if I'm running a kernel build in a tmpfs and I hit the sleep
> key, I need to go
On Thu, May 27, 2010 at 08:02:13PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
> > If you want to support forced suspend for laptops and you want to avoid
> > the risk of losing wakeups then you need in-kernel suspend blockers.
> > That's entirely orth
On Thu, 27 May 2010 18:57:19 +0100
Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
>
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
>
> If you want to support forced suspend for laptops and you wan
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > > Why would you care about the screen for a network
On Thu, May 27, 2010 at 07:02:04PM +0100, Alan Cox wrote:
> > This is still racy. Going back to this:
> >
> > int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> > char foo;
> > struct sockaddr addr;
> > connect (input, &addr, sizeof(addr))
> > while (1) {
> >if (read(input, &foo,
> > So PCs with current ACPI don't get opportunistic suspend capability. It
> > probably won't be supported on the Commodore Amiga either - your point ?
>
> Actually, the reverse - there's no terribly good way to make PCs work
> with scheduler-based suspend, but there's no reason why they wouldn'
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Thomas Gleixner wrote:
>
> > Crap. Stop beating on those lost wakeup events. If we lose them then
> > the drivers are broken and do not handle the switch over correctly. Or
> > the suspend mechanism is broken as it does not evaluate th
On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> >
> > > If that's what you're aiming for then you don't need to block
> > > applications on hardware access b
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 just does not make use of this
> > information. Blockers just paper over this by s
On Thu, 2010-05-27 at 18:54 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:
>
> > How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
> > handler gets run, handler generates a task wakeup, runqueue isn't empty,
> > we run stuff.
>
On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
>
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
>
> If you want to support forced suspend for laptops and you want
On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
>
> > If that's what you're aiming for then you don't need to block
> > applications on hardware access because they should all already have
> > idled themselves.
>
> Corr
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > My question was about explicit suspend states, not implicitly handling
> > > an identical state based on scheduler constraints. Suspe
On Thu, 27 May 2010 18:40:19 +0100
Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> >
> > _WHY_!?
>
> Because if I'm running a kernel build in a tmpfs and I hit the sleep
> ke
On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
> Shall we henceforth stop confusing forced suspend for laptops and
> powersaving a running system?
If you want to support forced suspend for laptops and you want to avoid
the risk of losing wakeups then you need in-kernel suspend b
On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> If that's what you're aiming for then you don't need to block
> applications on hardware access because they should all already have
> idled themselves.
Correct, a well behaved app would have. I thought we all agreed that
well behaved
> network packet arrives. The difference between these scenarios is large.
Your application seems to change desired outcome every email. Sorry but
you need to explicitly explain and define a policy in full that we can
test ideas against. Otherwise this is useless.
> > If you have wake-on-lan then
On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:
> How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
> handler gets run, handler generates a task wakeup, runqueue isn't empty,
> we run stuff.
If you're using idle-based suspend without any forced idling or bloc
On Thu, May 27, 2010 at 07:46:37PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > > Then that's an application bug right there, isn't it?
> > >
> > > If should have listened to the win
On Thu, 2010-05-27 at 13:44 -0400, Alan Stern wrote:
> You close your laptop's lid and throw the machine into a backpack. At
> that time you want it to suspend even though it may not be idle.
>
> > We've been trying to tell you you don't need that.
>
> And I'm trying to tell you that you do.
On Thu, 2010-05-27 at 19:42 +0200, Florian Mickler wrote:
> If in the imaginery situation where userspace can aquire certain
> wakeup-constraints and loose certain wakeup-constraints, then it could
> be that the system enters suspend without empty runqueues.
No. Wakeup constaints simply delay wa
On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote:
> > ACPI provides no guarantees about what level of hardware functionality
> > remains during S3. You don't have any useful ability to determine which
> > events will generate wakeups. And from a purely practical point of view,
> > since
On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > > Why would you care about the screen
On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> >
> > _WHY_!?
>
> Because if I'm running a kernel build in a tmpfs and I hit the sleep
> key,
On Thu, 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:
>
> > Even if we could use suspend-via-deep-idle-state on PCs,
>
> ( see Alan Cox's argument on PCs )
>
> > we still need to be able to enter suspend while the system isn't idle.
>
> _WHY_!?
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 a plain
> > > idle C-State is wr
> What is a "Correctly implemented driver" in this case? One that receives
> a wakeup event and then prevents suspend being entered until userspace
> has acknowledged that event? Because that's what an in-kernel suspend
> blocker is.
Kernel side maybe - but even then its a subset of expressing
On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > Why would you care about the screen for a network event?
> >
> > Because the application that needs
On Thu, 27 May 2010, Thomas Gleixner wrote:
> > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > should be removed? Or "echo disk >/sys/power/state"? They pay no
>
> mem should be replaced by an idle suspend to ram mechanism
In other words, you are suggesting that not onl
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > we still need to be able to enter suspend while the system isn't idle.
>
> _WHY_!?
Because if I'm running a kernel build in a tmpfs and I hit the sleep
key, I need to go to sleep. Blocking processes on driver access isn't
suffi
On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:
> On some platforms (like those with ACPI), deeper power-savings are
> available by using forced suspend than by using idle.
Sounds like something that's fixable, doesn't it?
> That used to be
> the case on Android. Arve has said that it is
On Thu, 27 May 2010, Thomas Gleixner wrote:
> Crap. Stop beating on those lost wakeup events. If we lose them then
> the drivers are broken and do not handle the switch over correctly. Or
> the suspend mechanism is broken as it does not evaluate the system
> state correctly. Blockers are just pape
On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:
> Even if we could use suspend-via-deep-idle-state on PCs,
( see Alan Cox's argument on PCs )
> we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
We've been trying to tell you you don't need that.
--
To uns
On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> > > How (and why) does the WoL (which may be *any* packet, not just a magic
> > > one) turn the screen back on
On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
>
> They may be different conceptually. Nevertheless, Android uses forced
> suspend as a form of power saving. Until better mechanisms are in
> place, it makes sense.
So let them, doesn't mean we have to merge it. Or will you saw your foot
On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> > How (and why) does the WoL (which may be *any* packet, not just a magic
> > one) turn the screen back on?
>
> Why would you care about the screen for a network event?
B
On Thu, 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
> > > Opportunistic suspend is just a deep idle state, nothing else.
> >
> > No. The useful property of opportunistic suspen
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 just does not make use of this
> information. Blockers just paper over this by sprinkling
> do_not_suspend() calls all over the place.
On Thu, 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
> >
> > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > should be removed? Or "echo disk >/sys/power/state"? They pay no
> > attention to latencies or other requirements.
>
On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
>
> > Suppose X (or whatever windowing system) will block all clients that try
> > to draw when you switch off your screen.
> >
> > How would we not wake them when we do tur
On Thu, 2010-05-27 at 18:23 +0100, Matthew Garrett wrote:
> ACPI provides no guarantees about what level of hardware functionality
> remains during S3. You don't have any useful ability to determine which
> events will generate wakeups. And from a purely practical point of view,
> since the late
On Thu, May 27, 2010 at 06:30:41PM +0100, Alan Cox wrote:
> > > Opportunistic suspend is just a deep idle state, nothing else.
> >
> > No. The useful property of opportunistic suspend is that nothing gets
> > scheduled. That's fundamentally different to a deep idle state.
>
> Nothing gets schedu
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Felipe Balbi wrote:
>
> > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > >If people don't mind, here is a greatly simplified summary of the
> > >comments and objections I have seen so far on this thread:
> > >
> >
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 a plain
> > idle C-State is wrong. It's not different at all. You just use a
> > different mechanism
On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
> Suppose X (or whatever windowing system) will block all clients that try
> to draw when you switch off your screen.
>
> How would we not wake them when we do turn the screen back on and start
> servicing the pending requests again?
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, 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 laten
> > Opportunistic suspend is just a deep idle state, nothing else.
>
> No. The useful property of opportunistic suspend is that nothing gets
> scheduled. That's fundamentally different to a deep idle state.
Nothing gets scheduled in a deep idle state either - its idle. We leave
the idle state to
On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > You still need the in-kernel suspend blockers if you want to guarantee
> > that you can't lose wakeup events. But yes, if you're not concerned
> > handling badly behaved applications
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, 2010-05-27 at 18:16 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > > No. The useful property of opportunistic suspend is that nothing gets
> > > scheduled. That's fundamentall
Hi,
On Thu, May 27, 2010 at 07:04:38PM +0200, ext Thomas Gleixner wrote:
Opportunistic suspend is just a deep idle state, nothing else. If the
overall QoS requirements allow to enter that deep idle state then the
kernel goes there. Same decision as for all other idle states. You
don't need any u
On Thu, May 27, 2010 at 07:04:24PM +0200, ext Alan Stern wrote:
On Thu, 27 May 2010, Felipe Balbi wrote:
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
>If people don't mind, here is a greatly simplified summary of the
>comments and objections I have seen so far on this thread:
On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > No. The useful property of opportunistic suspend is that nothing gets
> > scheduled. That's fundamentally different to a deep idle state.
>
> I think Alan and Thomas but
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > No. Suspend blockers are designed to ensure that suspend isn't racy with
> > > respect to wakeup events. The bit that mitigates badl
On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
>
> Does this mean you believe "echo mem >/sys/power/state" is bad and
> should be removed? Or "echo disk >/sys/power/state"? They pay no
> attention to latencies or other requirements.
Those are a whole different beast, those are basically
On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Sure, if you're not using opportunistic suspend then I don't think
> > > there's any real need for the userspace side o
On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > Sure, if you're not using opportunistic suspend then I don't think
> > there's any real need for the userspace side of this. The question is
> > how to implement something with the u
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
>
> > I can't speak for Thomas, but I'm certainly not arguing that you don't
> > need something that looks more like the blocker side of the logic *in
> > kernel*, because there is stuff that y
On Thu, 27 May 2010, Felipe Balbi wrote:
> On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> >If people don't mind, here is a greatly simplified summary of the
> >comments and objections I have seen so far on this thread:
> >
> > The in-kernel suspend blocker implementation is
On Thu, 27 May 2010, Alan Cox wrote:
> That's all your need to do it right.
>
> In kernel yes your device driver probably does need to say things like
> 'Don't go below C6 for a moment' just as a high speed serial port might
> want to say 'Nothing over 10mS please'
>
> I can't speak for Thomas, b
On Thu, 27 May 2010, 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 down stuff and setup e
301 - 400 of 481 matches
Mail list logo
