On Thu, Oct 18, 2012 at 11:24:40AM +0200, Peter De Schrijver wrote: > On Tue, Oct 16, 2012 at 07:03:43PM +0200, Stephen Warren wrote: > > On 10/16/2012 02:06 AM, Peter De Schrijver wrote: > > >>> Even though we have plan to use coupled cpuidle, I still prefer to go > > >>> with the LP2 driver first. Then adding one more patch to support coupled > > >>> cpuidle based on LP2 driver. This is good for history. And if there is > > >>> any issue, it's more easy to roll back to the stable one. > > >> > > >> I don't think that implementing it one way and then changing to a > > >> different way will benefit history at all. It'll make the history more > > >> complicated. What exactly is the problem with just using coupled cpuidle > > >> from the start? If we did merge this implementation now, then switch to > > >> coupled cpuidle later, when do you think the switch would happen? > > > > > > Before we consider doing this, I think we should have some idea on how > > > frequently we run into the situation where CPU0 is idle but a secondary > > > core is not. Depending on that we can then decide how useful coupled cpuidle > > > would be for us. > > > > Would it not be 75% of the time where we have 1 of 4 CPUs active? At > > least, that's assuming that all work is evenly distributed amongst CPUs, > > and hence it's random which CPU is the last to go idle, but perhaps > > that's not the case if CPU0 is somehow special workload-wise? > > > > Depends, at least it used to be possible to tune the scheduler to prefer > CPU0 if the workload can run on a single CPU. > I just noticed https://lwn.net/Articles/518834/. If we can configure this to prefer CPU0 in case all work can be done on a single core, we shouldn't hit the case were a secondary CPU is the only active CPU for a significant period of time. Cheers, Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
