inhibiting suspend via dbus

[Deepak Saxena]

On Aug 09 2008, at 15:34, John Gilmore was caught saying:
> > As it turns out, the activity update control panel needs to inhibit
> > suspend, too, otherwise we go to sleep in the middle of downloading
> > large activities (Firefox, TamTam, etc).
> >
> > Chris, could you make a little wiki page explaining how to interact w/
> > ohm via dbus to temporarily inhibit suspend, and send me the [[link]]?
> >  I figure other people who want to do other long-lived tasks could use
> > this information, too; it should perhaps be included in the activity
> > API docs.  (Does Browse properly inhibit suspend during download?  It
> > probably should.)
> 
> No, this is the wrong approach.
> 
> We shouldn't be patching every program to "avoid suspending" at various
> times.  We should be improving the heuristic that the system (Ohm) uses
> to decide when to suspend.  Once we have better information from the
> kernel about what the running processes are doing, we'd just have to
> rip out all the little kludges inserted into every program.

I don't think we want kludged in every program, but I also think
that for power management to work efficiently and for us to be
able to enable/disable the right HW at the right time, we need
a way for applications to be involved.

> Normally, when a TCP connection is active, even a suspended XO should
> break out of suspend when the next packet arrives from the other end.
> Only if it happens to suspend in the brief interval between receiving
> that packet and asking for the next one, will such a suspend persist
> indefinitely.  But there may be bugs there (e.g. #6528).

The fact that we're dropping packets that wake us up is a bug, but 
orthogonal to how we implement a system-wide power management policy 
and interfaces to change that policy at runtime.  

> We already have bugs because Read was hacked to force suspends, and it
> turns out it's suspending at the wrong times (#6645, #6684).  Let's
> not add more bugs by hacking more activities to force or unforce
> suspends.

Looking at the #6645, I agree we need some better way of dealing with
this.  The problem with the pure hereustic approach is that there may
be times when we don't have enough knowledge about the system state
and more importantly the user's behaviour to really make a decision 
without information from the application. For example, if I am streaming
music on my computer, and I walk away for sometime, it may be perfectly
OK to go to do a full suspend, or it maybe the case that I don't want to 
go to sleep but it's OK for me to shutdown the screen.  Simply looking at 
what is the current process doing (using network and audio resources) is 
not enough to make a smart judgement on what to do in this situation. 
There must be a way for the user to tell the application what to do
and a way for the application to pass that information into the system 
power manager.

> We should understand why ohm isn't noticing that the activity updater
> isn't idle.  Should Ohm be looking for a higher cpu idle% in the
> seconds before it suspends?  Should it be looking for minimal numbers
> of context switches per second before it suspends?  What does the
> system look like when the updater is running?  If we can confine our
> suspend-kludge patches to one place (ohm) we'll be much better off in
> the medium and long term.

What happens when the updater is modified?  Do we have to reanalyze 
the behaviour pattern everyime we have chage the updater and then rewrite 
the heurestic code in OHM? What if I'm doing something else at the
same time as running the updater which completely modifies the behaviour?
And what about when we change to a new kernel and the scheduler behaviour
changes (see #7603)?

~Deepak

-- 
Deepak Saxena - Kernel Developer - dsaxena at laptop.org