RDTSCP and System.nanoTime

[Jeremy Manson]

Hi David,

If the TSC is reliable, and we know its rate, then currentTimeMillis
can be calculated by taking the time the usual way once at (roughly)
the same time as you read the TSC.  You can then figure out the time
later by simply reading the TSC and doing arithmetic.  You would want
to resynchronize pretty often, but not more than, say, once every few
seconds.

I read "IA32_TSC_AUX provides a 32-bit field that is initialized by
privileged software with a signature value (for example, a logical
processor ID)." as meaning that it had to be a value unique to that
processor, but now that you mention it, I'm not sure where "signature"
is defined.  Presumably, something very definite and/or well-defined
is done by Linux and Windows.

It sounds as if the best thing to do is wait and see how these
features get implemented.  There are probably kernel people we can
ask.

Jeremy

On Thu, Aug 12, 2010 at 1:37 PM, David Holmes <David.Holmes at oracle.com> wrote:
> Hi Jeremy,
>
> nanoTime has always been implemented using the highest-resolution time
> source exposed by the OS, so as soon as Linux uses a reliable-TSC (for
> CLOCK_MONOTONIC) the VM would utilize it. (Solaris jumps through hoops to
> make the TSC "reliable").
>
> Doing a CPU specific nanoTime could be entertained if it were worthwhile.
> (But people have more issues with currentTimeMillis() performance than
> nanoTime in general).
>
> It's a pity that Intel didn't also make the frequency available as
> calculating that is a PITA. :)
>
> Also note:
>
> "IA32_TSC_AUX provides a 32-bit field that is initialized by privileged
> software with a signature value (for example, a logical processor ID)."
>
> the content of the aux reg is not required to be a processor id. I don't see
> anything that tells you how to find out what it actually is.
>
> Cheers,
> David Holmes
>
> Jeremy Manson said the following on 08/13/10 04:01:
>>
>> Hi folks,
>>
>> Motivation: the overhead of System.nanoTime and
>> System.currentTimeMillis on Linux is pretty awful if you are trying to
>> use them frequently.
>>
>> The motivation for not replacing System.nanoTime with a RDTSC-based
>> approach was, as I understand it, based on two things:
>>
>> 1) The older timestamp counters were processor-cycle based, and shut
>> down when the system was in power-savings mode, and
>>
>> 2) It used to be impossible to compensate for TSC drift between
>> processors.
>>
>> The Nehalem architecture seems to have fixed these problems with
>> Invariant TSC (which runs at a constant rate regardless of power
>> state) and support for the IA32_TSC_AUX register (which tells you what
>> CPU you are using when you read the counter).  See section 16.11.1 and
>> 16.11.2 of:
>>
>> http://www.intel.com/Assets/PDF/manual/253668.pdf
>>
>> I don't see code that looks like this in os_linux.cpp, so I was
>> wondering if you guys had any plans to support it.
>>
>> Thanks!
>>
>> Jeremy
>