[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: Peter Zijlstra on 3 Jun 2010 03:50 On Wed, 2010-06-02 at 22:13 +0200, Florian Mickler wrote: > On Wed, 02 Jun 2010 12:21:28 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > Do you switch your pc on and off manually? Sometimes? Really? > (if not, you are probably a kernel hacker *g*) Yeah, when my Radeon GPU locks up the bus _again_, and yeah to replace parts, but no, not otherwise ;-) But I've been doing that for pretty much as long as I've had a computer. > 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? Make suspend an idle state and teach apps to go real quiet. (Then again, that only really works when regular network packets can wake the machine for my case). > > 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_ Therefore I say, fix the worprocessor to not actually do anything if its not poked at -- not too hard, wordprocessors really don't need to do anything on their own, and you can do your last backup cycle when the window becomes invisible and stop the timer until the document changes again. 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. You really only ever want to freeze broken apps. And even for those I would prefer it if I got notified some app is stupid, then I could either fix it, or choose not to use it. You can also teach cron to listen to dbus messages telling it about the screen state and postpone jobs -- but please make that a configurable thing, I really like all that work done at 4am when I'm (usually) not around to be bothered by it. > 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? Well, at that point suspend is nothing more than an idle state, and platform code needs to somehow inform the idle state governor that active net connections need to prevent that idle state from being used. If you want to call that suspend blockers, then sure, but its a long way away from the explicit scheme proposed at the start of this thread. -- 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: Peter Zijlstra on 3 Jun 2010 04:10 On Wed, 2010-06-02 at 20:18 -0700, mark gross wrote: > However; one could go to a dual list (like the scheduler) and > move inactive nodes from an active to inactive list, /me suggests you take a new look at the scheduler, those lists disappeared more than 10 releases ago. We use RB-trees these days. -- 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: Peter Zijlstra on 3 Jun 2010 04:20 On Wed, 2010-06-02 at 23:58 -0700, Brian Swetland wrote: > > I haven't poked around too much with how things work in SMP > environments -- are there per-cpu idle threads? Yes, and we recently grew the infrastructure for asymmetric MP in the processing capacity sense. -- 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: Alan Cox on 3 Jun 2010 06:00 > [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 code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is. That should be trivial in the usual case because 99% of the time you can hot path the QoS entry changing is the latest one there have been no other changes If it is valid I can use the cached previous aggregate I cunningly saved in the top QoS entry when I computed the new one (ie most of the time from the kernel side you have a QoS stack) > We've had a number of attempts at fixing this, but I think the proper fix is to bolt a "disable C-states > x" interface into cpu_idle that bypases pm_qos altogether. Or, perhaps add a new pm_qos API that does the equivalent operation, overriding whatever constraint is active. We need some of this anyway for deep power saving because there is hardware which can't wake from soem states, which in turn means if that device is active we need to be above the state in question. -- 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: Peter Zijlstra on 3 Jun 2010 06:10
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 code really wasn't made to deal with such > hot path use, as each such change triggers a re-computation of what > the aggregate qos request is. > > That should be trivial in the usual case because 99% of the time you can > hot path > > the QoS entry changing is the latest one > there have been no other changes > If it is valid I can use the cached previous aggregate I cunningly > saved in the top QoS entry when I computed the new one > > (ie most of the time from the kernel side you have a QoS stack) Why would the kernel change the QoS state of a task? Why not have two interacting QoS variables, one for the task, one for the subsystem in question, and the action depends on their relative value? > > We've had a number of attempts at fixing this, but I think the > proper fix is to bolt a "disable C-states > x" interface into cpu_idle > that bypases pm_qos altogether. Or, perhaps add a new pm_qos API that > does the equivalent operation, overriding whatever constraint is > active. > > We need some of this anyway for deep power saving because there is > hardware which can't wake from soem states, which in turn means if that > device is active we need to be above the state in question. Right, and I can imagine that depending on the platform details and not the device details, so we get platform hooks in the drivers, or possible up in the generic stack because I don't think NICs actually know if there are open connections. -- 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/ |