On Mon, Jun 10, 2013 at 06:30:25PM +0100, Sebastian Capella wrote:
Hi,
I haven't heard back from anyone regarding my last request. If there are no objections, I'll go ahead and publish this patch to LKML and LAKML.
No objections from me, Sebastian. When you have time and the inclination to do so, I would like to see a more detailed explanation on what are your QoS constraints on the embedded mobile, for my personal enlightment.
Best regards, Liviu
Thanks,
Sebastian
On 29 May 2013 07:37, Sebastian Capella <sebastian.capella@linaro.orgmailto:sebastian.capella@linaro.org> wrote: Hi Guys,
Sorry, I think the conversation went pretty far from my patch.
Concerning my original patch, do you have any more ideas or concerns?
I'm not sure I have a clear idea what, if anything, needs to be changed.
I was able to verify it on the TC2 platform without issue.
Thanks again for all of your time.
Sebastian
On 22 May 2013 11:51, Sebastian Capella <sebastian.capella@linaro.orgmailto:sebastian.capella@linaro.org> wrote: Quoting Dave Martin (2013-05-22 11:22:36)
Currently not. This partly depends on whether the target residency is supposed to be a hint about the rough order of magnitude of the expected idle period, or whether it's supposed to be a strict contract.
In effect, I think it's a hint which steers the choice of powerdown state, rather than soemthing with a strong real-time guarantee attached to it. In that case shaving the firmware latency off this value before using it may not be worth it. If the specified target residency is small enough that this makes a significant difference, this suggests a very short period of actual powerdown, which may not outweigh its own overheads in terms of power-saving.
Thanks Dave, Liviu,
Sorry, you've caught me mixing terms and concepts.
I agree, target residency to me also is more an estimate of the cost vs. benefit for a state.
The cstates also define a latency parameter that is used for limiting selection of certain states by the governor. This is affected by QoS constraints, which we use alot in embedded. This is the one needed for realtime use that is tricky with host os' additional latency.
Both latency and target residency would need some adjustment for embedded mobile if we have additional overhead as it becomes very important to squeeze this as much as possible. For latency, microseconds count as we cannot allow a cstate which will fail to meet our qos constraints.
Thanks,
Sebastian