On Tue, May 21, 2013 at 02:08:29PM -0700, Sebastian Capella wrote: > Thanks Liviu! > > Some comments below.. > > Quoting Liviu Dudau (2013-05-21 10:15:42) > > ... Which side of the interface are you actually thinking of? > > Both, I'm really just trying to understand the problem. > > > I don't think there is any C-state other than simple idle (which > > translates into an WFI for the core) that *doesn't* take into account > > power domain latencies and code path lengths to reach that state. > > I'm speaking more about additional c-states after the > lowest independent compute domain cstate, where we may add additional > cstates which reduce the power further at a higher latency cost. These > may be changing power states for the rest of the SOC or external power > chips/supplies. Those states would effectively enter the lowest PSCI > C-state, but then have additional steps in the CPUIdle hw specific > driver. > > > I don't know how to draw the line between the host OS costs and the > > guest OS costs when using target latencies. On one hand I think that > > the host OS should add its own costs into what gets passed to the > > guest and the guest will see a slower than baremetal system in terms > > of state transitions; > > I was thinking maybe this also.. Is there a way to query the state > transition cost information through PSCI? Would there be a way to > have the layers of hosts/monitors/etc contribute the cost of their > paths into the query results?
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. That's just my view -- others may disagree Cheers ---Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
