On 29 January 2014 10:57, Preeti Murthy <preeti.l...@gmail.com> wrote: > How about simplifying this design by doing the below? > > 1. Since anyway cpufreq governors monitor load on the cpu once every > 5ms, *tie it with tick_sched_timer*, which also gets deferred when the cpu > enters nohz_idle.
Its configurable. We can change sampling time to whatever we want. Some might be selecting it as 30 ms. > 2. To overcome the problem of running this job of monitoring the load > on every cpu, have the *time keeping* cpu do it for you. > > The time keeping cpu has the property that if it has to go to idle, it will do > so and let the next cpu that runs the periodic timer become the time keeper. > Hence no cpu is prevented from entering nohz_idle and the cpu that is busy > and first executes periodic timer will take over as the time keeper. > > The result would be: > > 1. One cpu at any point in time will be monitoring cpu load, at every sched > tick > as long as its busy. If it goes to sleep, then it gives up this duty > and enters idle. > The next cpu that runs the periodic timer becomes the cpu to monitor the load > and will continue to do so as long as its busy. Hence we do not miss > monitoring > the cpu load. > > 2. This will avoid an additional timer for cpufreq. > > 3. It avoids sending IPIs each time this timer gets modified since there is > just > one CPU doing the monitoring. > > 4. The downside to this could be that we are stretching the functions of the > periodic timer into the power management domain which does not seem like > the right thing to do. Looks good, but AFAIK timerkeeper is still to be implemented? Also the best solution is to get rid of this timer completely by getting inputs from scheduler. Probably some ARM/Linaro folks are working on it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
