On 01/25/2013 01:38 AM, Willy Tarreau wrote:
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.
Ok, I'll resend the patch with a proper description later today.
thanks
-john
--
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
