On Monday, May 30, 2016 6:15:50 PM CEST Tina Ruchandani wrote:
... But after reviewing the previous discussion I think I should try to find people with 32-bit systems who can tell me whether they see a performance regression.
I'll do that and try to get an answer soon.
Please consider this patch as a first-cut draft attempt to get the ball rolling on this again. It would be nice to take this to completion, given all the effort you and Arnd put into the discussion last here. I didn't get the chance to discuss this with Arnd before sending it out, and its likely that what I implemented is different from and sub-par compared to what he had mind. The discussion last year didn't seem to mention the need for a 32-bit divide, I ended up needing it here. Also, Arnd has some efficient interfaces in mind - introducing light-weight ktime_get_us() perhaps. I don't know how that would be done, and hence I tried the other approach he had suggested.
I'm looking at this again now:
- do_gettimeofday(&now); - n = now.tv_usec - f->sent.tv_usec; - n += (now.tv_sec - f->sent.tv_sec) * USEC_PER_SEC; + ktime_get_ts64(&now); + delta = timespec64_sub(now, f->sent); + n = ((int32_t) (delta.tv_sec)) * USEC_PER_SEC + + delta.tv_nsec / NSEC_PER_USEC;
and find them to be almost exactly equivalent in terms of operations: The difference between do_gettimeofday and ktime_get_ts64() is that the former has an extra constant 32-bit division by NSEC_PER_USEC, which is the same thing you are addingn in the new version here.
Also, the use of a 64-bit tv_secs variable is not visible in the end, because do_gettimeofday puts a local copy of that type on the stack, and you end up converting the seconds to 32-bit either way.
I don't think there is any difference in speed between reading realtime and monotonic time either, so your version just helps avoid the fallback to jiffies and the overflow without any downsides.
Arnd