lkml.org 
[lkml]   [2015]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Xen-devel] [PATCH] xen-time: decreasing the rating of the xen clocksource below that of the tsc clocksource for dom0's
On 13/01/15 15:42, Boris Ostrovsky wrote:
> On 01/13/2015 04:52 AM, David Vrabel wrote:
>> On 13/01/15 08:14, Imre Palik wrote:
>>> From: "Palik, Imre" <imrep@amazon.de>
>>>
>>> In Dom0's the use of the TSC clocksource (whenever it is stable
>>> enough to
>>> be used) instead of the Xen clocksource should not cause any issues, as
>>> Dom0 VMs never live-migrated. The TSC clocksource is somewhat more
>>> efficient than the Xen paravirtualised clocksource, thus it should have
>>> higher rating.
>>>
>>> This patch decreases the rating of the Xen clocksource in Dom0s to 275.
>>> Which is half-way between the rating of the TSC clocksource (300) and
>>> the
>>> hpet clocksource (250).
>> I'm happy with this but would like to see acks from those who objected
>> to v1.
>>
>> David
>>
>>> --- a/arch/x86/xen/time.c
>>> +++ b/arch/x86/xen/time.c
>>> @@ -487,6 +487,10 @@ static void __init xen_time_init(void)
>>> int cpu = smp_processor_id();
>>> struct timespec tp;
>>> + /* As Dom0 is never moved, no penalty on using TSC there */
>
> Again, why not any PV guest with TSC_MODE_NEVER_EMULATE?

Surely if TSC_MODE_NEVER_EMULATE is set then the TSC is /not/ stable
across a guest save/restore thus the PV clocksource must be used?

I don't think we want to assume that TSC_MODE_NEVER_EMULATE => never
migrate.

David


\
 
 \ /
  Last update: 2015-01-13 17:21    [W:0.208 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site