Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3998149pxv; Tue, 13 Jul 2021 08:32:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz8hSld4RMdwgcOnbRTEsIIEnW1qazuASY1jihMQZ6il5VAXbiVAwrwseN7qBSbkvj40uyr X-Received: by 2002:a05:6402:1014:: with SMTP id c20mr6577788edu.380.1626190361752; Tue, 13 Jul 2021 08:32:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626190361; cv=none; d=google.com; s=arc-20160816; b=GtjJbUGYRGf1S+OC/TkXV91tTHaYtxXQPf/Jllq/0WnIYPu67+1XV99+eWYpfcGizt /5SeatxzyssUVo3Pe40PqiUb6ZlQbAaoaENicyn6SB5mJ6zirDBJkMsrioyqMQ9bCyUp DZJ/Afew0nthmnNtwoRr6LgrYKlpQWGc5Pp1NUfzRGPltnaSbo54MyOkswXp1XHRXYCk 62K32ZNJUKjpl2nTPftbqZlDIS5uX/jpPaE6SJY0ih0YesQF51bCveM23ZM+2o7UZ2Me oIj6yXqz8syBs1Je/7KJhhXwphg0vLxM5F+wvAVIn/4YFWoy7vSZk2AdBW1Y0MS+0F6I u8NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:date:from:dkim-signature; bh=4JLkHqv40CmG7uaGdF0kdga9f1jTWV2dMUz/yJdaz2M=; b=zRwCiYU+o3/qqPKahcNZ4voeIhfw5KyDDEznlWg4wSL/TuQWwZmkxTJv6CemJqMq5y VlNdZiyVLGRGUf8XE+mmlQThVxb04NjaWgtPhWeX8l8zupuiGrg78qt1Aji6uRQihBxW kkATgTfB6VMcQ8PbKnww1JNE5APMKBoyWU75qe5i99xJoge8p07nwiwWohl2LD6Kgapt YLv+n66fFTpghnHAWn82thEteFXUOoeeHBkTIu+E0AaIZQBnfJaSSi+InQaCPkK250tX 685Xhphp+EifnYie/eD34+jQ0m0ZAktE2hs/ENqTONJjIOi1IGnjvTkDj7Y7yF1mBEDD xQNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@anisinha-ca.20150623.gappssmtp.com header.s=20150623 header.b="1bEk/KHy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b1si9419268edr.456.2021.07.13.08.32.17; Tue, 13 Jul 2021 08:32:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@anisinha-ca.20150623.gappssmtp.com header.s=20150623 header.b="1bEk/KHy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237065AbhGMPeP (ORCPT + 99 others); Tue, 13 Jul 2021 11:34:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236970AbhGMPeP (ORCPT ); Tue, 13 Jul 2021 11:34:15 -0400 Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AF96C0613DD for ; Tue, 13 Jul 2021 08:31:25 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id j199so19981747pfd.7 for ; Tue, 13 Jul 2021 08:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anisinha-ca.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=4JLkHqv40CmG7uaGdF0kdga9f1jTWV2dMUz/yJdaz2M=; b=1bEk/KHyfwxs/+kzKDxxY7JFrLkIpI/mXtVxGpwQyXXefp3BWTb4QPBxyFaJnM8EnD BMRcSyHVcxIcR3lHi5ZLTdj6OV0HrN29C8EON3OVFEoaAf8fk1AFYRRD+5G1G2eDsmbW 6QoUhOtXl2fruqEPnFtIwFj3uzeXJ3LYEEol0dZpGboJDOHaiJu9mbV9iW37lcFM7Kyk GKuUt0OY3YBZvsAlTYdBgLziLouoamMyxv/XwdJqsoXIcyQAIQPVZ8OiEs1z8fELgT/5 StXBFLTQMWFxtxxuomVEvWutWnEVo+oYMdzXHfY3Y8TcUSEwGEDcLxxOKT9YILmPIBAC Vghw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=4JLkHqv40CmG7uaGdF0kdga9f1jTWV2dMUz/yJdaz2M=; b=ifVwySV0QNKekFyzms544WUn7czeaN0wqqV9zlUoV1Tf5aZ4UozWSIGWA95uiouOK/ Bw835baTPyt9OYnWTkvrIEY3rsD68mQlMz/Z2+reMzZaJI15wq0yuPRLeRVjN0o+UEGK Y/LPUTbod2QruG1gSr2ubemVwEVsu74j2MKPjx6r1zHfWIVB2LYl17fKYwKTg8wRa6Dd ezjXSb6VEcXeGpABAY0aDBI6KIBDYo6enXZv3I1r+hiqsi03pbvuADLSggSwx4QfQbO5 RRfKdq5f30zcJVyVu/FVIoDx5hWxzyftTvW4iFGWB2tX0vS7zy376Jg2/Cybne615DRf 6+NQ== X-Gm-Message-State: AOAM533OWVBptO82Y94Zv3cJ85EDKGozO4FnquGG7yUN4EM6b7Nh8XHh KjUeNLKLMLaotW/+yu7D2Wh2uQ== X-Received: by 2002:a62:2942:0:b029:2f4:e012:fb23 with SMTP id p63-20020a6229420000b02902f4e012fb23mr5021592pfp.55.1626190284569; Tue, 13 Jul 2021 08:31:24 -0700 (PDT) Received: from anisinha-lenovo ([115.96.158.88]) by smtp.googlemail.com with ESMTPSA id j13sm3545843pjl.1.2021.07.13.08.31.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jul 2021 08:31:24 -0700 (PDT) From: Ani Sinha X-Google-Original-From: Ani Sinha Date: Tue, 13 Jul 2021 21:01:06 +0530 (IST) X-X-Sender: anisinha@anisinha-lenovo To: Peter Zijlstra cc: Wei Liu , Ani Sinha , linux-kernel@vger.kernel.org, anirban.sinha@nokia.com, mikelley@microsoft.com, "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Dexuan Cui , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , linux-hyperv@vger.kernel.org Subject: Re: [PATCH] Hyper-V: fix for unwanted manipulation of sched_clock when TSC marked unstable In-Reply-To: <20210713131756.GD4170@worktop.programming.kicks-ass.net> Message-ID: References: <20210713030522.1714803-1-ani@anisinha.ca> <20210713130446.gt7k3cwlmhsxtltw@liuwe-devbox-debian-v2> <20210713131756.GD4170@worktop.programming.kicks-ass.net> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Jul 2021, Peter Zijlstra wrote: > On Tue, Jul 13, 2021 at 01:04:46PM +0000, Wei Liu wrote: > > On Tue, Jul 13, 2021 at 08:35:21AM +0530, Ani Sinha wrote: > > > Marking TSC as unstable has a side effect of marking sched_clock as > > > unstable when TSC is still being used as the sched_clock. This is not > > > desirable. Hyper-V ultimately uses a paravirtualized clock source that > > > provides a stable scheduler clock even on systems without TscInvariant > > > CPU capability. Hence, mark_tsc_unstable() call should be called _after_ > > > scheduler clock has been changed to the paravirtualized clocksource. This > > > will prevent any unwanted manipulation of the sched_clock. Only TSC will > > > be correctly marked as unstable. > > > > Correct me if I'm wrong, what you're trying to address is that > > sched_clock remains marked as unstable even after Linux has switched to > > a stable clock source. > > > > I think a better approach will be to mark the sched_clock as stable when > > we switch to the paravirtualized clock source. > > No.. unstable->stable transitions are unsound. You get to switch to your > paravirt clock earlier. > I believe manipulating sched_clock was never the intention of the original author who added the code to mark tsc as unstable on hyper-V: commit 88c9281a9fba67636ab26c1fd6afbc78a632374f Author: Vitaly Kuznetsov Date: Wed Aug 19 09:54:24 2015 -0700 x86/hyperv: Mark the Hyper-V TSC as unstable The original author simply wanted to mark TSC as unstable on hyper-V systems because of reasons the above commit log will describe. Sched clock manipulation happened accidentally because from where the mark_tsc_unstable() was being called. This patch simply fixes this. Michael Kelly from Microsoft has tested this patch already. --Ani