[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: Alan Cox on 2 Jun 2010 08:00 On Wed, 02 Jun 2010 11:10:51 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote: > > > > If I understood you correctly then you can shutdown the CPU in idle > > completelty already, but that's not enough due to: > > > > 1) crappy applications keeping the cpu away from idle > > 2) timers firing > > > > Would solving those two issues be sufficient for you or am I missing > > something ? > > Aren't the container snapshot/resume people fighting the same set of > problems here? And virtualisation - its a big one for virtualisation because if you've got 1000 misbehaving guests generating 100 wakeups a second you've got a problem .... 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: mark gross on 2 Jun 2010 09:40 On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hj�nnev�g wrote: > On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920(a)gmail.com> wrote: > > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote: > ... > >> +static void update_target_val(int pm_qos_class, s32 val) > >> +{ > >> + � � s32 extreme_value; > >> + � � s32 new_value; > >> + � � extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value); > >> + � � new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value); > >> + � � if (extreme_value != new_value) > >> + � � � � � � atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value); > >> +} > >> + > > > > Only works 1/2 the time, but I like the idea! > > It fails to get the righ answer when constraints are reduced. �But, this > > idea is a good improvement i'll roll into the next pm_qos update! > > > > I think it would be a better idea to track your constraints with a > sorted data structure. That way you can to better than O(n) for both > directions. If you have a lot of constraints with the same value, it > may even be worthwhile to have a two stage structure where for > instance you use a rbtree for the unique values and list for identical > constraints. I don't agree, we went through this tree vrs list discussion a few times before in other areas of the kernel. Wherever the list tended to be short, a simple list wins. However; we can try it, after we have some metrics and stress test cases identified we can measure its effectivenes against. --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: James Bottomley on 2 Jun 2010 11:10 On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: > 2010/6/1 James Bottomley <James.Bottomley(a)suse.de>: > > On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote: > >> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley <James.Bottomley(a)suse.de> wrote: > >> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: > >> >> On Tuesday 01 June 2010, James Bottomley wrote: > >> >> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: > >> >> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: > >> >> > > > >> >> > > > You're the one mentioning x86, not me. I already explained that some > >> >> > > > MSM hardware (the G1 for example) has lower power consumption in S3 > >> >> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any > >> >> > > > suspend from idle C state. The fact that current x86 hardware has the > >> >> > > > same problem may be true, but it's not entirely relevant. > >> >> > > > >> >> > > As long as you can set a wakeup timer, an S state is just a C state with > >> >> > > side effects. The significant one is that entering an S state stops the > >> >> > > process scheduler and any in-kernel timers. I don't think Google care at > >> >> > > all about whether suspend is entered through an explicit transition or > >> >> > > something hooked into cpuidle - the relevant issue is that they want to > >> >> > > be able to express a set of constraints that lets them control whether > >> >> > > or not the scheduler keeps on scheduling, and which doesn't let them > >> >> > > lose wakeup events in the process. > >> >> > > >> >> > Exactly, so my understanding of where we currently are is: > >> >> > >> >> Thanks for the recap. > >> >> > >> >> > 1. pm_qos will be updated to be able to express the android suspend > >> >> > blockers as interactivity constraints (exact name TBD, but > >> >> > probably /dev/cpu_interactivity) > >> >> > >> >> I think that's not been decided yet precisely enough. I saw a few ideas > >> >> here and there in the thread, but which of them are we going to follow? > >> > > >> > Well, android only needs two states (block and don't block), so that > >> > gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines > >> > like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to > >> > describe these, but if all we're arguing over is the define name, that's > >> > progress. > >> > >> I think we need separate state constraints for suspend and idle low > >> power modes. On the msm platform only a subset of the interrupts can > >> wake up from the low power mode, so we block the use if the low power > >> mode from idle while other interrupts are enabled. We do not block > >> suspend however if those interrupts are not marked as wakeup > >> interrupts. Most constraints that prevent suspend are not hardware > >> specific and should not prevent entering low power modes from idle. In > >> other words we may need to prevent low power idle modes while allowing > >> suspend, and we may need to prevent suspend while allowing low power > >> idle modes. > > > > Well, as I said, pm_qos is s32 ... it's easy to make the constraint > > ternary instead of binary. > > 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. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. James -- 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: Florian Mickler on 2 Jun 2010 15:50 On Wed, 02 Jun 2010 10:05:11 -0500 James Bottomley <James.Bottomley(a)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 other way around. > > Depends. If you block the system from going into low power idle, does > that mean you still want it to be fully suspended? > > If yes, then we do have independent constraints. If not, they have a > hierarchy: > > * Fully Interactive (no low power idle or suspend) > * Partially Interactive (may go into low power idle but not > suspend) > * None (may go into low power idle or suspend) > > Which is expressable as a ternary constraint. > > James > But unblocking suspend at the moment is independent to getting idle. If you have the requirement to stay in the highest-idle level (i.e. best latency you can get) that does not (currently) mean, that you can not suspend. To preserve that explicit fall-through while still having working run-time-powermanagement I think the qos-constraints need to be separated. <disclaimer: just from what I read> Provided you can reach the same power state from idle, current suspend could probably also be implemented by just the freezing part and a hint to the idle-loop to provide accelerated fall-through to lowest power. </disclaimer> At that point, you could probably merge the constraints. But the freezing part is also the hard part, isn't it? (I have no idea. Thomas seems to think about cgroups for that and doing smth about the timers.) Cheers, Flo -- 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: Florian Mickler on 2 Jun 2010 16:20
On Wed, 02 Jun 2010 12:21:28 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-06-02 at 03:00 -0700, Arve Hj�nnev�g wrote: > > 2010/6/2 Peter Zijlstra <peterz(a)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 modes with suspend. > > > > > > I think it is you who is confused. For power management purposes suspend > > > is nothing more but a deep idle state. > > > > No, idle is transparent, suspend is not. > > Which is where the problem is, it should be. > > > Why would I add suspend blockers to the code I want to prevent running? > > Because what you want might not be what others want. Suppose you're fine > with your torrent client/irc client/etc.. to loose their network > connection when you're not behind your desktop so you don't add suspend > blockers there. > > Me, I'd be ready to administer physical violence if either of those lost > their connections when I wasn't around to keep the screen-saver from > kicking in. Do you switch your pc on and off manually? Sometimes? Really? (if not, you are probably a kernel hacker *g*) I assume, in general, there are only a few reasons to shut down a machine: 1. One has to do maintainance on the hardware or somehow needs to interrupt the power supply. 2. One wants to save power. 3. One wants to go easy on the hardware. 4. ...? Obviously, for reason 1 we need to maintain the shutdown-paths indefinitely. But the rest are usecases that are similar to the suspend-blocker usecases. You know that you are not using the machine and going through the pain to shut down your machine. You have to do it manually. Why? > This leads to having to sprinkle magic dust (and lots of config options) > all over userspace. Something that gets esp interesting with only a > boolean interface. A userspace daemon could keep track of what applications can be ignored. The wordprocessor probably should not keep the system busy. As well as a running firefox. It is a hard problem. But we have _no way of deciding any of this in the kernel_! > > In the example above, having an active net connection would prevent my > desktop from suspending, but what if another platform can maintain net > connections while suspended? Do we then end up with arch specific code > in the net-stack? I'm sure DaveM would love that. > If it is driver knowledge, then it goes into the driver. If it is platform knowledge, then it goes into the platform code. I think that is a clear requirement to keeping sanity. The problem is there independently of suspend blockers. If the system can suspend with network up, then you shure as hell want to suspend even if the network is up. So it would actually be a reason for any kind of "suspend blockers" scheme. Wouldn't it? Cheers, Flo -- 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/ |