On Fri, Jan 25, 2013 at 10:16:50AM +0100, Romain Francoise wrote: > Hi, > > John Stultz <[email protected]> writes: > > > Of course, the xtime_cache is updated at the bottom of > > update_wall_time(). So the early return on (offset < > > timekeeper.cycle_interval), causes the xtime_cache to not be updated. > > Then in hrtimer_get_softirq_time(), we pull current_kernel_time() which > > uses the non-updated xtime_cache, and that likely causes timers to fire > > with half-second granularity. > > Makes sense, that explains why the application runs much slower but > appears to be doing nothing, it's waiting on timers that aren't firing at > the required frequency... > > > So I think reverting 61b76840ddee647c0c223365378c3f394355b7d7 is the > > right call, since it isn't really appropriate for 3.6.32. > > > Although the issue it addresses (inconsistencies in the _COARSE > > clockids) would return, those had been present for quite some time > > without complaint. So another possible solution would be the following > > (fair warning, totally untested). Mind giving it a try to see if it > > resolves the issue? > > I'm happy to confirm that with this patch applied on top on v2.6.32.60, > everything works again. Also, as you suspected disabling NO_HZ makes the > issue disappear as well in vanilla v2.6.32.60. > > Thank you for the quick response and patch! > > Willy, do you want to apply this additional patch, or just revert > 61b76840ddee647c0c223365378c3f394355b7d7?
What I understand is that the original fix is desirable even if the issue was not critical. So probably that we should keep the original fix and apply this new one on top of it. Anyway I'll follow John's advice, he's clearly the expert on time management. Thanks for your tests Romain! Willy -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
