[ohm] Updated use case for moble platforms.

[Kimmo Hämäläinen]

On Tue, 2007-05-29 at 08:46 -0700, ext Gross, Mark wrote:
...
> >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.

I think the QoS could be communicated to the kernel by writing
to /proc/<pid>/something, as in the case of adjusting the OOM killer
policy for the process in /proc/<pid>/oom_adj. This writing to /proc
could be done by some OHM-connected process, because in some cases QoS
might depend on the hardware and system state (available from sysfs).

BR; Kimmo

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