From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753013AbbAMQeA (ORCPT ); Tue, 13 Jan 2015 11:34:00 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:24510 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752163AbbAMQd6 (ORCPT ); Tue, 13 Jan 2015 11:33:58 -0500 Message-ID: <54B548DA.60402@oracle.com> Date: Tue, 13 Jan 2015 11:33:30 -0500 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Vrabel , Imre Palik , xen-devel@lists.xenproject.org CC: "Palik, Imre" , x86@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Anthony Liguori , "H. Peter Anvin" , Thomas Gleixner Subject: Re: [Xen-devel] [PATCH] xen-time: decreasing the rating of the xen clocksource below that of the tsc clocksource for dom0's References: <1421136862-15083-1-git-send-email-imrep.amz@gmail.com> <54B4EAC7.2080105@citrix.com> <54B53CDD.7070400@oracle.com> <54B542C0.4070701@citrix.com> <54B54513.8060604@oracle.com> In-Reply-To: <54B54513.8060604@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/13/2015 11:17 AM, Boris Ostrovsky wrote: > On 01/13/2015 11:07 AM, David Vrabel wrote: >> 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" >>>>> >>>>> 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? > > TSC is declared stable when !d->disable_migrate && !d->arch.vtsc, with > vtsc being 0 with TSC_MODE_NEVER_EMULATE (per domain_cpuid()). I think I inverted domain_cpuid's logic here but my point was that we use'd use combination of TSC_MODE_NEVER_EMULATE and CPUID flag indicating TSC stability to pick the clocksource. -boris > > And if TSC is not stable as seen by CPUID (which would be the case if > disable_migrate is not set) then kernel won't use TSC as clocksource > anyway, regardless of rating value, won't it? > > -boris > >> >> I don't think we want to assume that TSC_MODE_NEVER_EMULATE => never >> migrate. >> >> David >