RDTSCP and System.nanoTime

[David Holmes]

Jeremy Manson said the following on 08/14/10 03:52:
> 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 have no problem with the OS doing this, but I wouldn't want the VM to 
have to do it. :)

> 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.

True even if not a processor id it likely has to be unique to a processor.

> 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.

I'm sure if you search lkml there will be some existing discussions on 
this topic.

David

> 
> 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