[ohm] monitoring INPUT state

[Gross, Mark]

>-----Original Message-----
>From: Rob Taylor [mailto:rob.taylor at codethink.co.uk]
>Sent: Friday, August 24, 2007 7:01 AM
>To: Gross, Mark
>Cc: Nils Faerber; ohm-devel
>Subject: Re: [ohm] monitoring INPUT state
>
>Gross, Mark wrote:
>> Sorry about the outlook text munging.  Comments below.
>>
>>> -----Original Message-----
>>> From: Rob Taylor [mailto:rob.taylor at codethink.co.uk]
>>> Sent: Thursday, August 23, 2007 5:59 AM
>>> To: Gross, Mark
>>> Cc: Nils Faerber; ohm-devel
>>> Subject: Re: [ohm] monitoring INPUT state
>>>
>>> Gross, Mark wrote:
>>>>> From: ohm-devel-bounces at lists.freedesktop.org [mailto:ohm-devel-
>>>>> bounces at lists.freedesktop.org] On Behalf Of Nils Faerber
>>>>> Sent: Monday, July 09, 2007 8:28 AM
>>>>> To: ohm-devel
>>>>> Subject: Re: [ohm] monitoring INPUT state
>>>>>
>>>>> Gross, Mark schrieb:
>>>>> [...]
>>>>>>> For the idle usecase say... as a third source you could have a
>>>>>>> deliberate "unidle" source, i.e. an application could want to
>>>> trogger
>>>>>>> the idle "watchdog" manually. This would be a third source (i.e.
>>>> X11,
>>>>>>> input/event/*, manual unidle). This could be useful for
>> applications
>>>>>>> that want to prevent the system to perform idle actions - not
very
>>>>>>> brilliant example since it could also disable the idle timer but
>>>> then
>>>>>> it
>>>>>>> could clash with the service that sets that values (which should
>> be
>>>>>>> session settings?).
>>>>>> This sounds scary to me.  We don't want to make the processor
more
>>>> busy
>>>>>> when trying to save battery life buy running a busy loop daemon
for
>>>>>> kicking a watch dog looking for inactivity at the UI level.
>>>>>>
>>>>>> I like the idea of an inactivity watch dog facility.  It would
help
>>>> to
>>>>>> understand the different classes of subsystem inactivity one
needs
>> a
>>>>>> watchdog on.  From this thread I see we only have xorg
inactivity.
>>>>> And this xorg idle is bound to input devices which is IMHO pretty
>> weak.
>>>> It would be good to drill down on what's weak about it, and try to
>> get
>>>> into a requirement definition mind set for the sub system's Ohm
>> depends
>>>> on.
>>> I've pretty much decided on using xorg idle for the default idle
plugin
>>> - with the next release of xorg, X will listen to all input devices
>>> advertised in HAL.
>>>
>>> Of course, it's also plausible to do another idle plugin with the
same
>>> interface that could, say, listen to all input devices directly.
>>>
>>> One thing I'd like to do, but still haven't, is to allow other
plugins
>>> to signal user activity by setting idle.state to 0, but I haven't
>> looked
>>> into that yet.
>>
>> Should idle.state == 0 (faulse) be non-idle and 1 be for idle?
>
>The new idle plugin interface has two keys, idle.state and
idle.timeout.
>idle.timeout is measured from the point of last activity. every time
>idle.timeout milliseconds have passed since idle, idle.state is
>incremented. This allows a policy plugin to have as many levels of
>idleness as it requires, just changing idle.timeout when idle.state
>increments. See policy/timeouts for an example.
>
>
>>> I think the right way forward for idleness of different subsystems
is
>> to
>>> have sepereate idle plugins - so current 'idle' becomes only user
input
>>> idle, and have network idle, audio idle, disk idle, etc.
>>
>> I think this is a very good idea, but I have to wonder what user mode
>> could possibly do with a disk-idle or audio-idle event.  Yes, we
would
>> turn-off the devices subject to some pre-defined wakeup latency
>> constraint.  What I'm wrestling with is where these actions belong,
in
>> user mode or in kernel mode...
>>
>> Do we make the lower level subsystems idle aware and have them
>> auto-magically do these types of things, or do we force user mode to
>> deal with them?  I'm sure it will be a mixture of both, and user mode
>> will likely do it first and embarrass the kernel guys into doing
it...
>
>Yes, that's exactly my take. In reality the kernel knows a lot more
>about it than we do, so things like turning off devices should be done
>there, depending on constraints we pass from userland. But it's gonna
be
>a while before the kernel gets a decent interface for this, so I think
>for now a lot will happen at the userland level (and of course doing it
>here should give some good ideas of what such a kernel interface should
>look like)

We'll have to keep in touch then.  I'm trying to push on the kernel
interface side of the equation.  It would be cool if we both have some
common abstractions in our work.  I'm really keen on latency, throughput
and timeouts.  If Ohm could try to express things in terms of these
abstractions somewhere in its stack whenever possible that will make
future integration with kernel enabling easier.

>
>>>>>> But, I can imagine: disk inactivity, audio inactivity, network
>>>>>> inactivity, process inactivity, interrupt inactivity.  Where each
>>>>>> "could" have a watchdog event go off to wake up some user mode
>>>> process
>>>>>> or kernel preference.
>>>>>>
>>>>>>> A, good example: An ebook reader which does auto scrolling - the
>>>> user
>>>>>>> does not make inputs but simply reads the book. Here you the X11
>>>> idle
>>>>>>> counter and the input/event would methods would fool you.
>>>>>> Auto scrolling without user input?  That won't be too useable for
>> me.
>>>>> I know at least half a dozen of people near me that use this
almost
>>>>> daily to read ebooks - an application renders the text and does
>> smooth
>>>>> scrolling. Ideally the spead is tuned to your reading speed so you
>> have
>>>>> a contiuous reading experience - quite convenient.
>>>> Hmm.  I should try such a thing someday.  Perhaps someone could
send
>> me
>>>> a pointer to such a reader off list?
>>> There needs to be a way for a user application to tell ohm to
inhibit
>>> various behaviour. Usecases are media players, which would want to
>>> inhibit backlight (if playing video) and suspend (always),
slideshows
>>> (backlight, suspend) and of course autoscrolling ebook readers..
>>>
>>
>> From my perspective the way to inhibit various behavior is to specify
>> acceptable use and wake up latencies per plug in.
>
>That sounds an interesting idea! Can you elaborate or give some
examples
>of how you see it working?

Ok, this is the way I abstract the power problems in my own head:

* We want the system to do the most aggressive power management it can,
at all times (the more automatic the better) subject to usability and
performance constraints.

* We expect hardware to become smarter and more capable of extreme
throttling over the short term.

* The hardware knows or will know how to talk in terms of, latencies,
throughputs, and time outs.

I look at the problem in terms of latencies (wake up and operational),
throughputs, and idle timeouts.  The only places this abstraction fails
me is for brightness, volume, and perhaps RF transmitter strength (well,
RF gain could be inferred from a network latency and throughput
parameters)

The following are some scenarios that where identified that could help
clarify my thoughts.  Note, that some of these may not be actionable in
this context but they are examples of how you can infer
power/performance behavior from latency (wakeup and operational),
throughput, and idle time out parameters:

Graphics:
-- QoS performance specified in terms of throughput (bits or pixels/sec)
If use case doesn't need high pixel rates, turn of accelerators.
-- Latency for bringing HW acceleration on line could influence
usability so if and acceptable wake up latency is provided then the
subsystem could save power without effecting usability based on wake up
latency and throughput information.

Platform suspend:
-- the choice to go into S3 or S4 is a function of acceptable wake up
latency.
-- the delay in which to drop into a suspend state is a idle time out.

Hard disk:
-- spin down delay is a function of idle time out and acceptable wake up
latency.  If acceptable wake up latency is too short then spin down is
disabled.

WiFi:
-- transmitter power state could be defined by, operational latency
(voip/games), 
-- if bandwidth needs are small (static HTML viewing) you don't need to
run the transmitter at high power, so throughput is a viable parameter.
-- idle network time out could be used to save additional power in the
radio. Subject to an acceptable wake up latency constraint.

Audio:
-- idle time out to turn off the CODEC / amplifier subject to acceptable
wake up latency.
-- hiqh quality vrs low quality audio could be determined by latency and
throughput parameters.  Power savings at the audio hardware level could
be had.

USB:
-- idle time out to start turning off parts of the stack.
-- acceptable wake up latencies to constrain shutting down too much.

CPU_DMA:
-- idle time outs to drop into deeper and deeper "C-states" (CPU sleep
states)
-- acceptable wake up latencies constrain how deep of sleep state the
CPU is allowed to go into when idle.

You get the picture...


>
>>
>> BTW: I'm very close to posting a kernel patch to put into place a QoS
>> infrastructure that will enable usermode latency needs be
communicated
>> to the lower levels in a reasonable way.
>
>
>Nice! do send me a pointer when you've posted it :)
>

It looks like we'll (Intel) have some sort of web page focusing on the
kernel enabling of some latency, throughput and timeout aware power
management to complement OHM and the Moblin/PPM.  When its up I'll send
a link.  (I'll be happy to sent the link to the RFC posting I'm going to
make soon if you like.)

--mgross