Github user vanzin commented on the pull request:
https://github.com/apache/spark/pull/8766#issuecomment-141164621
This is what my `clock_gettime(3)` man page says:
Historical note for SMP systems
Before Linux added kernel support for CLOCK_PROCESS_CPUTIME_ID and
CLOCK_THREAD_CPUTIME_ID, glibc implemented these clocks on many platâ
forms using timer registers from the CPUs (TSC on i386, AR.ITC on
Itanium). These registers may differ between CPUs and as a consequence
these clocks may return bogus results if a process is migrated to
another CPU.
If the CPUs in an SMP system have different clock sources, then
there is no way to maintain a correlation between the timer registers since
each CPU will run at a slightly different frequency. If that is
the case, then clock_getcpuclockid(0) will return ENOENT to signify this
condition. The two clocks will then be useful only if it can be
ensured that a process stays on a certain CPU.
The processors in an SMP system do not start all at exactly the same
time and therefore the timer registers are typically running at an
offset. Some architectures include code that attempts to limit
these offsets on bootup. However, the code cannot guarantee to accurately
tune the offsets. Glibc contains no provisions to deal with these
offsets (unlike the Linux Kernel). Typically these offsets are small
and therefore the effects may be negligible in most cases.
Since glibc 2.4, the wrapper functions for the system calls
described in this page avoid the abovementioned problems by employing the kerâ
nel implementation of CLOCK_PROCESS_CPUTIME_ID and
CLOCK_THREAD_CPUTIME_ID, on systems that provide such an implementation
(i.e., Linux
2.6.12 and later).
That, and some comments on the links that you posted, lead me to believe
that `System.nanoTime` is, in the worst case, no worse than
`System.currentTimeMillis`. But, caveat emptor, since the above man page only
applies to Linux. `java.util.concurrent` seems to use `nanoTime`, so we already
rely on it more than we might expect.
I haven't read the code in `ExecutorAllocationManager` in detail to see how
it would behave when `System.currentTimeMillis` goes backwards. It seems to me
that at least that case would not happen with `nanoTime`, assuming the
conditions listed in the man page exist.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
