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.cape...@linaro.org<mailto:sebastian.cape...@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.cape...@linaro.org<mailto:sebastian.cape...@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 > > > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
