Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-06-02 at 22:13 +0200, Florian Mickler wrote:
> On Wed, 02 Jun 2010 12:21:28 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/