SERVER-2114 Don't use select() timeouts for fast coarse timing #416
Conversation
On Linux, the CLOCK_MONOTONIC_COARSE clock is very fast to read, as little as 25ns on my little laptop. It's resolution is limited to the kernel tick resolution, which on most servers will be 100hz; the current kludge uses select() timeouts of 10ms, so this should be acceptable. On other platforms, the penalty for bona fide syscalls should be nearly negligable - the real syscalls on Linux take around 1 microsecond on my little laptop, and I can't imagine they would be that much worse on Windows/OSX/Solaris. Even if it is worse, avoiding 100 wakeups a second from select() may very well offset the penalty.
|
(I have an alternate patch that leaves the current implementation for all platforms but Linux, if there is opposition to using the monotonic time syscalls in other OS's) |
|
Hi Calvin, Before we can accept any pull request, we have two main requirements. (1) reference a SERVER ticket, (2) make sure you've signed the contributor agreement. I see you already have the SERVER ticket taken care of, so that's great! Now we need the contributor agreement. This is explained in CONTRIBUTING.rst in the source tree. The form is at http://www.10gen.com/legal/contributor-agreement Even though it's not "required" in the form, please make sure you specify your GitHub username. This will help us verify compliance more quickly in the future. Thank you for contributing, and I apologize for the delay in getting back to you. |
| // Make sure our Linux has the timer we need | ||
| #if defined(__linux__) | ||
| #ifndef CLOCK_MONOTONIC_COARSE | ||
| #error "Your ancient kernel doesn't support CLOCK_MONOTONIC_COARSE: upgrade to v2.6.31 or newer" |
There was a problem hiding this comment.
We have to support version 2.6.18 and up for sure.
We may even go back further.
There was a problem hiding this comment.
Hmm, ok. Is there a specific distro you've in mind there? I got 2.6.31 out of the upstream git tree, but it's possible the COARSE clock was backported by some distros... not sure. I could try and check.
The truly correct thing to do is to check for it at runtime I suppose, and fall back to MONOTONIC_RAW. Problem is, go back far enough and all you have is MONOTONIC, which is skewed by ntp updates...
There was a problem hiding this comment.
@erh what kernel versions need to be supported today? It's almost two years later, so I'm wondering if the situation has changed at all
There was a problem hiding this comment.
We still support RHEL 5, which is still at 2.6.18, but with a lot of
patches.
On Wed, Jan 14, 2015 at 4:55 PM, Ben McCann notifications@github.com
wrote:
In src/mongo/util/net/listen.cpp
#416 (diff):@@ -51,6 +52,23 @@
#endif
+// Make sure our Linux has the timer we need
+#if defined(linux)
- #ifndef CLOCK_MONOTONIC_COARSE
#error "Your ancient kernel doesn't support CLOCK_MONOTONIC_COARSE: upgrade to v2.6.31 or newer"@erh https://github.com/erh what kernel versions need to be supported
today? I'd like to try to resurrect this PR, but need to know what to
support—
Reply to this email directly or view it on GitHub
https://github.com/mongodb/mongo/pull/416/files#r22973616.
There was a problem hiding this comment.
Thanks @erh! Really appreciate it. It's very helpful to know what we're targeting.
@jcalvinowens it looks like since we have to target 2.6.18 that CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID, CLOCK_REALTIME, and CLOCK_MONOTONIC are available according to the man page. Is knowing that we have to target 2.6.18 enough to unblock you?
|
this was closed by accident, but the source repo appears to have been deleted, so can't be reopened. |
configuration strings to pass __wt_checkpoint so that __wt_checkpoint knows it's a checkpoint, not a file close. This is because we use __wt_schema_worker() to call __wt_checkpoint and there's no way to pass flags through __wt_schema_worker() to the underlying function. Fix this by creating two underlying functions, __wt_checkpoint and __wt_checkpoint_close, both of which can call __checkpoint_worker() with the right flags, and quit generating fake configuration strings in the places we're doing that. closes mongodb#416
https://jira.mongodb.org/browse/SERVER-2114
I have tested this on Linux. I do not have access to machines running 64-bit OSX or Solaris, and I don't have Visual Studio, so those platforms are not even compile tested.