From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC53EEB64D9 for ; Mon, 19 Jun 2023 16:17:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232055AbjFSQQk (ORCPT ); Mon, 19 Jun 2023 12:16:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232285AbjFSQQ3 (ORCPT ); Mon, 19 Jun 2023 12:16:29 -0400 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 931A9A2 for ; Mon, 19 Jun 2023 09:16:28 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-4f849605df4so4717454e87.3 for ; Mon, 19 Jun 2023 09:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1687191387; x=1689783387; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=leWAGSFt7ZRZTiV68pCw/bS8IvitjMX4ssop8zLCQLk=; b=KPqCsivXnm5TyZDYJDfxHUfqAQuL7m7AzIjRWUYJlgYoKbRmBF3nqbCkkTdaANIqGM /rF+TgrYHg41YGJJVwU11kD4kBQ/ohoHUvNVt22jSuDjqEOlcZg3cP+z5gGj9kdej6qB 0m7HNbU3XcBvw8pz9RNgbCzRnd4RIB0XxocRsraAqPgHVCp6XYwxwplNUja+5OVL5zeq STxkQGP+CIKy5gswxMYXz21pDLuHGDTrAjQKcFuMP4FUxSQwp6wa/VMFAGHU6ohm3XzD 0TjR4W8+B5ELk/hZjqGMF6iNVDWv6VQEoAJWF+LTLbV5H++K+0keHkgww5X0RKGZfXhl PskA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687191387; x=1689783387; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=leWAGSFt7ZRZTiV68pCw/bS8IvitjMX4ssop8zLCQLk=; b=VbMRZvSWJqDrglP5NZ7TTtTAV6DhE09DsEZtKknwdLBdJoJyeIteyQs1VX+bhI8XBt yr7tVcH9+HzRnVn78bNg11moHlivPhRLVxcKUfo1yy4wfWC1eFQQoIdbfuuK3CQeBkyd vXXbM/53knM6jmTwTDqOZER0i3/d2fTYTHt63PnJKtFfRoNsEmz2HKo4V9PX4Cn2yg8X s4nqhAx9Feqrtmrw99DlMBULcTdlxMOW5Z5pOFVddYoGKmSJfkpnVErNNefP9lsHQ5Vy /klPkSJ4rlrywjJPeydwR96GH/+o3dZbbOUfuN76y/mDiiv0Yhcp7IpoDxQp0ovwQOeN rS1A== X-Gm-Message-State: AC+VfDwyT5dDQU7gTQxzoWWbyqqmBSPWdy8E20a+StnYk9QbgMSAWhrZ psk4IWimHCwI4KLtRAGsr/Z2yA== X-Google-Smtp-Source: ACHHUZ5nU8CDnotXYqoQdUIkgLe6l8Zg3bvGXgRhke6j+ElbL2Iu5NUib34O1rrxegBd2AJ+aG1bqQ== X-Received: by 2002:a05:6512:288:b0:4f6:924:8fa3 with SMTP id j8-20020a056512028800b004f609248fa3mr5669498lfp.58.1687191386660; Mon, 19 Jun 2023 09:16:26 -0700 (PDT) Received: from ?IPV6:2a05:6e02:1041:c10:13d0:1b6c:ce40:5429? ([2a05:6e02:1041:c10:13d0:1b6c:ce40:5429]) by smtp.googlemail.com with ESMTPSA id c9-20020a05600c0ac900b003f7eeec829asm146142wmr.10.2023.06.19.09.16.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jun 2023 09:16:26 -0700 (PDT) Message-ID: Date: Mon, 19 Jun 2023 18:16:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 1/1] clocksource: hyper-v: Rework clocksource and sched clock setup Content-Language: en-US To: Michael Kelley , kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org References: <1686325621-16382-1-git-send-email-mikelley@microsoft.com> From: Daniel Lezcano In-Reply-To: <1686325621-16382-1-git-send-email-mikelley@microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/06/2023 17:47, Michael Kelley wrote: > Current code assigns either the Hyper-V TSC page or MSR-based ref counter > as the sched clock. This may be sub-optimal in two cases. First, if there > is hardware support to ensure consistent TSC frequency across live > migrations and Hyper-V is using that support, the raw TSC is a faster > source of time than the Hyper-V TSC page. Second, the MSR-based ref > counter is relatively slow because reads require a trap to the hypervisor. > As such, it should never be used as the sched clock. The native sched > clock based on the raw TSC or jiffies is much better. > > Rework the sched clock setup so it is set to the TSC page only if > Hyper-V indicates that the TSC may have inconsistent frequency across > live migrations. Also, remove the code that sets the sched clock to > the MSR-based ref counter. In the cases where it is not set, the sched > clock will then be the native sched clock. > > As part of the rework, always enable both the TSC page clocksource and > the MSR-based ref counter clocksource. Set the ratings so the TSC page > clocksource is preferred. While the MSR-based ref counter clocksource > is unlikely to ever be the default, having it available for manual > selection is convenient for development purposes. > > Signed-off-by: Michael Kelley The patch does not apply, does it depend on another patch? Rejected chunk: --- drivers/clocksource/hyperv_timer.c +++ drivers/clocksource/hyperv_timer.c @@ -485,15 +485,9 @@ static u64 notrace read_hv_clock_msr_cs(struct clocksource *arg) return read_hv_clock_msr(); } -static u64 noinstr read_hv_sched_clock_msr(void) -{ - return (read_hv_clock_msr() - hv_sched_clock_offset) * - (NSEC_PER_SEC / HV_CLOCK_HZ); -} - static struct clocksource hyperv_cs_msr = { .name = "hyperv_clocksource_msr", - .rating = 500, + .rating = 495, .read = read_hv_clock_msr_cs, .mask = CLOCKSOURCE_MASK(64), .flags = CLOCK_SOURCE_IS_CONTINUOUS, -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog