On Thu, 5 Aug 2010, Florian Mickler wrote:

quoted text
> On Thu, 5 Aug 2010 07:33:59 +0200
> Florian Mickler <florian@mickler.org> wrote:
>
>> On Wed, 4 Aug 2010 16:10:03 -0700
>> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
>>
>> No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle
>> is used. For idle decision a certain subset of tasks is ignored.
>>
>> Where suspend is prevented by the trusted
>> process in android-world taking a wakelock, here it would just prevent
>> the system from going idle by arming timers.
>>
>> This would be pretty equivalent to the suspend-blocker scheme and not
>> introduce new userspace api. But the downside is, as Arve pointed out,
>> that now one can not get full-idle-power-leverage while suspend
>> is blocked.
>>
>> [1] http://permalink.gmane.org/gmane.linux.kernel/1018452  and
>> following
>>
>>
>> Cheers,
>> Flo
>>
>
> There are a few downsides that got mentioned already in reponse..  I got
> a little lagged behind.
>
> There are upsides to this approach like not
> having a special purpose userspace api, conceptually integrating
> suspend into the idle mechanism ..

first off, a good summary of that I've been saying, thanks.

quoted text
> Short summary of the cons that got mentioned:
>
>  -  applications need to resort to polling to keep the system
> 	out of idle (->  system will never be fully idle)

true, although the power difference between a system that is 
completelyidle (but with a wavelock held) and a system where one 
application is polling every 10 seconds or so is _really_ low.

quoted text
>  -  the race between deciding to suspend and becoming active
> 	again is not handled

this one I will admit to not fully understanding, it sounds like there are 
opptions here, but I don't understand them or their trade-offs

quoted text
>  -  no special statistics available

or no special statistics needed. Powertop is already avaible to analyse a 
system and report what processes are keeping it awake. Why would this not 
be enough?

quoted text
>  -  the timers of the ignored applications will behave unexpected
> 	(as the monotonic clock is not stopped)... while applications
> 	have already to cope with network-loss, other side effects of
> 	suspend without monotonic clock stopped are to be expected...

I'm not sure this is true. there's nothing stopping the suspend (when it 
finally does happen) from stopping the monotonic clock. The core of my 
proposal is tweaking how we decide to suspend. Other than the possibility 
that we decide to suspend between timers (and set an alarm to wake up when 
a timer would go off) I'm not suggesting that the suspend itself change 
once it's finally triggered.

David Lang
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/