On Tue, May 1, 2012 at 3:43 AM, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote: > Hi Colin, > > On Mon, Apr 30, 2012 at 10:37:30PM +0100, Colin Cross wrote: <snip> >> On Tegra3, the deepest individual cpu state for cpus 1-3 is OFF, the >> same state the cpu would go into as the first step of a transition to >> a deeper power state (cpus 0-3 OFF). It would be more optimal in that >> case to bypass the SMP cross call, and leave the cpu in OFF, but that >> would require some way of disabling all wakeups for the secondary cpus >> and then verifying that they didn't start waking up just before the >> wakeups were disabled. I have just started considering this >> optimization, but I don't see anything in the existing code that would >> prevent adding it later. > > I agree it is certainly an optimization that can be added later if benchmarks > show it is needed (but again it is heavily platform dependent, ie technology > dependent). > On a side note, disabling (or move to the primary) wake-ups for "secondaries" > on platforms where every core is in a different power domain is still needed > to avoid having a situation where a CPU can independently get out of idle, ie > abort idle, after hitting the coupled barrier. > Still do not know if for those platforms coupled C-states should be used, but > it is much better to have a choice there IMHO. Yes, that is the primary need for the coupled_cpuidle_parallel_barrier function - secondary cpus need to disable their wakeup sources, then check that a wakeup was not already pending and abort if necessary. > I have also started thinking about a cluster or multi-CPU "next-event" that > could avoid triggering heavy operations like L2 cleaning (ie cluster shutdown) > if a timer is about to expire on a given CPU (as you know CPUs get in and out > of idle independently so the governor decision at the point the coupled state > barrier is hit might be stale). It would be possible to re-check the governor to decide the next state (maybe only if the previous decision is out of date by more than the target_residency?), but I left that as an additional optimization. > I reckon the coupled C-state concept can prove to be an effective one for > some platforms, currently benchmarking it. > >> A simple measurement using the tracing may show that it is >> unnecessary. If the wakeup time for CPU1 to go from OFF to active is >> small there might be no need to optimize out the extra wakeup. > > Indeed, it is all about resetting the CPU and getting it started, with > inclusive L2 the power cost of shutting down a CPU and resuming it should be > low (and timing very fast) for most platforms. The limiting factor may be the amount of time spent in ROM/Trustzone code when bringing a cpu back online. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
