[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [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@xxxxxxxxx>
>>> 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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.