[ohm] Updated use case for moble platforms.

[Gross, Mark]

>-----Original Message-----
>From: Kimmo Hämäläinen [mailto:kimmo.hamalainen at nokia.com]
>Sent: Monday, May 28, 2007 6:41 AM
>To: Gross, Mark
>Cc: ohm-devel at lists.freedesktop.org
>Subject: Re: [ohm] Updated use case for moble platforms.
>
>On Fri, 2007-05-25 at 09:20 -0700, ext Gross, Mark wrote:
>> Please give me some feed back on what you think.
>>
>> http://ohm.freedesktop.org/wiki/UseCases?action=show
>
>Looks good. I added one use case about input method selection on a
>handheld.
>
>> I'm not sure if problems I'm starting to consider overlap what you feel
>> Ohm should handle.
>
>I think it could be beneficial to collect some draft requirements based
>on the use cases to some other wiki page.
>

I would like it if after a nice set of requirements are gathered that we partition the requirements between kernel features and user mode policy management things.


>It would be great if one could describe a state machine that reacts to
>hardware events and launches programs accordingly, using a high-level
>description language (maybe XML-based). OHM would then parse the
>description and implement it in a process.
>

I have a specific class of use cases on the brain and don't want to bias they discussions too much as Ohm is for mostly embedded applications.  However....

I'm looking at power management from a QoS latency point of view these days.  Every user power/performance need can be expressed in terms of acceptable latencies in various sub-systems.  With some kernel device pm enhancements one could see the problem reduced to aggregating the QoS latency constraints of the user programs and passing them down to the kernel to let it do whatever it can to maximize power performance without violating the QoS request.

We need a way to arbitrate the aggregate the requests ( min(...) ), provide some mechanism for the user to identify a process that's hurting performance (powerTOP with latency requests?)

Would we need a way of creating a database of latency constraints per power aware application.  Something for the system engineer to use for tuning the platform before it ships?  We don't want to have to re-compile every binary with different QoS constants to use if we don't have too.  (or do we?)

We need to identify the communications between the QoS requester and the kernel under various scenarios.  Startup, exit, kill -9, at runtime when program is idle (paused media play back), others....  What would make sense?  What's the easiest path to take?

Do we need to understand runtime-latency, idle-latency, and idle-trigger-delay or is just tracking runtime-latency good enough?


Feel free to call this line of thought off topic for Ohm.  I'm not 100% sure where these ideas belong and I'm hopping I'm not wasting bandwidth.

--mgross

>BR; Kimmo
>
>>
>> Thanks,
>>
>> --mgross
>> _______________________________________________
>> Ohm-devel mailing list
>> Ohm-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/ohm-devel