On 01/26/2013 08:51 AM, Romain Francoise wrote:
Hi John,
John Stultz <[email protected]> writes:
Do you have a simple reproduction case that you could share? Or maybe if
you could strace -T the problematic test and look for long stalls (and
let me know what syscall is having the problem)? Its likely the fix is
correct, but I want to make sure I really have the full scope of whats
going wrong here before we make another change.
I wrote a small test program to show the problem, which does 10 blocking
receives from an empty POSIX message queue with a 100ms timeout. On my
machine it runs consistently in 1.000s, which is what I expect. In a
virtual machine running a fixed 2.6.32 kernel (v2.6.32.60 + revert), it
runs consistently in 1.200s, I have no idea where the extra 200ms come
from but it's not important (low HZ?). In a virtual machine running the
buggy kernel (v2.6.32.60), it runs in approximately 4s, and it's pretty
obvious by watching the output that the timers do not fire in a consistent
manner.
Ok, thanks, this helped demonstrate the issue quite well.
Looking at the mqueue code your test calls, it uses CURRENT_TIME to
calculate the timeout end time. This is based off of the xtime_cache
value, which due to the problematic patch is updating at half-second
granularity, is always behind by up to a half second.
This same granularity miss-match (between a coarsely updated
CURRENT_TIME and gettimeofday) is actually also the cause of the extra
200ms delay you see. Since CURRENT_TIME is always up to a jiffy behind
the gettimeofday() time, if HZ=100, then 10ms per jiffy, and you're
iterating 10 times, so that's 100ms, but the prepare_timeout code adds a
jiffy as well (to avoid possibly firing early, since you're possibly
mid-way through the current jiffy). So 2 extra jiffies * 10 times = 200ms.
The mqueue code has actually changed since 2.6.32, and it now uses
absolute timeouts, so the kernel doesn't convert the value to a relative
timeout internally (which causes the error you're seeing).
Ok, so with all this explained, I feel confident that the new patch
resolves things properly, and will send it out here shortly.
By the way, I'm always looking for good timekeeping tests to try to
catch these sorts of things ahead of time.
My current set is here: https://github.com/johnstultz-work/timetests
Would you mind if I reworked your test case and added it to my suite? (I
might ask you resend it with a gpl header).
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
