On 01/24/2013 07:00 AM, Romain Francoise wrote:
Willy Tarreau <[email protected]> writes:What is your workload ?There are two separate workloads that are affected by this issue: - one is a pretty typical whole-distribution build, which gets 1.5x to 2x slower with v2.6.32.60 - the other is a code simulator, which is basically a bunch of processes communicating together using POSIX message queues (mq_timedsend() and mq_timedreceive()). It runs approximately 10x slower, but doesn't seem to use more CPU, it just sits there doing pretty much nothing. I managed to narrow the second workload down to a single test case, which runs in approximately 0.7s in v2.6.32.59 and 8s (!) in v2.6.32.60. Having a simple test case allowed me to do a full bisection in a test VM, and it ends on commit 61b76840ddee647c0c223365378c3f394355b7d7 ("time: Avoid making adjustments if we haven't accumulated anything"). And indeed, if I revert this commit from v2.6.32.60 then everything is back to normal.
Huh. That's curious.Especially since "time: Avoid making adjustments if we haven't accumulated anything" should really be shortcutting unnecessary work.
Do you see any similar regression behavior between 3.5 and 3.6 (when the same fix landed upstream)?
If not, I suspect there's some extra detail w/ xtime_cache and the non-logarithmic accumulation that we did prior to 2.6.33, that I missed.
Looking at the history of the corresponding source file, ec145babe754f
("time: Fix timeekeping_get_ns overflow on 32bit systems") might be
similar to what I'm seeing: timers not firing as they should on 32-bit
systems. I'm using a 32-bit kernel with an older 32-bit userspace from
Debian etch, in KVM.
Sorry, I'm missing some of the context here. Could you explain more about seeing timers not firing as they should? Is this strictly limited to 32-bit systems, or have you only gotten to test with those?
Mind sending me your dmesg? And let me know if you have any trivial test cases to demonstrate the issue. I'll get a similar 32bit kvm environment setup to try to reproduce.
Thanks for the heads up! -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
