On 08/30/2016 01:30 PM, Jan Beulich wrote:
On 30.08.16 at 14:08, wrote:
>> On 08/29/2016 10:36 AM, Jan Beulich wrote:
>> On 26.08.16 at 17:11, wrote:
On 08/25/2016 11:06 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> - Change init_tsctimer to skip all the te
>>> On 30.08.16 at 14:08, wrote:
> On 08/29/2016 10:36 AM, Jan Beulich wrote:
> On 26.08.16 at 17:11, wrote:
>>> On 08/25/2016 11:06 AM, Jan Beulich wrote:
>>> On 24.08.16 at 14:43, wrote:
> - Change init_tsctimer to skip all the tests and assume it's called
> only on reliable
On 08/29/2016 10:36 AM, Jan Beulich wrote:
On 26.08.16 at 17:11, wrote:
>> On 08/25/2016 11:06 AM, Jan Beulich wrote:
>> On 24.08.16 at 14:43, wrote:
This patch introduces support for using TSC as platform time source
which is the highest resolution time and most performant to
>>> On 26.08.16 at 17:11, wrote:
> On 08/25/2016 11:06 AM, Jan Beulich wrote:
> On 24.08.16 at 14:43, wrote:
>>> This patch introduces support for using TSC as platform time source
>>> which is the highest resolution time and most performant to get (~20
>>> nsecs).
>>
>> Is this indeed still
On 08/25/2016 11:06 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> This patch introduces support for using TSC as platform time source
>> which is the highest resolution time and most performant to get (~20
>> nsecs).
>
> Is this indeed still the case with the recently added fences?
>>> On 24.08.16 at 14:43, wrote:
> This patch introduces support for using TSC as platform time source
> which is the highest resolution time and most performant to get (~20
> nsecs).
Is this indeed still the case with the recently added fences?
> Though there are also several problems associate
Recent x86/time changes improved a lot of the monotonicity in xen timekeeping,
making it much harder to observe time going backwards. Although platform timer
can't be expected to be perfectly in sync with TSC and so get_s_time won't be
guaranteed to always return monotonically increasing values ac
