Hi John, John Stultz <[email protected]> writes:
> 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). I see, thanks for the explanation. I guess we never noticed the extra 2 jiffies per call in the original application, which I think uses a shorter timeout than my test case. > 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). Please feel free to use this code under whatever license you like. Thanks again for everything! -r -- 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
