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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D967C28CC3 for ; Thu, 30 May 2019 13:51:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7014925618 for ; Thu, 30 May 2019 13:51:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726876AbfE3NvJ (ORCPT ); Thu, 30 May 2019 09:51:09 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:53180 "EHLO mail-wm1-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725870AbfE3NvJ (ORCPT ); Thu, 30 May 2019 09:51:09 -0400 Received: by mail-wm1-f52.google.com with SMTP id y3so4034570wmm.2 for ; Thu, 30 May 2019 06:51:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=VJdacDVHBRo3cqkBw/isPcHDnC2ea++G9bD0r1ee6oo=; b=a1zAZOE49fO48si2ZAbWC63sV3B3kVsryhVVR/s/OAq2ZOySbyP1P6qjNUniujtksk gZdDJtfDl43bKUfgtwYwRsELTp+QTzMgXDCB8gMITtqOyBj4ZjH33waWQdlUyzQXoJrF LGLgbCz0964O6BSsdHiAH45lxCtpIya2ifNK7MFOOK3DeJdKjhBnKkrGpE/x1WDSxFwZ F5+Ft9vuZ4G+XB2sGKIiYbpjYvzAdkxaIsygxDnms4ShwmwJvNl1incVUuNXDFYt0GF0 r9ccQ2pM31UqPmgPAxgF1lq38lUC7Mwg+tWlXF9q6Tob4XmBEswx9O4vOf7ddpTAVm7h nLgg== X-Gm-Message-State: APjAAAUDGWWPs61+z0Xcs/+gGsY3WKsZ17q1VPLxaerUunfD424GYcmp MYUZ06ts0ZuuGx64y/pqmatFZw== X-Google-Smtp-Source: APXvYqwclqccELRhv/Sc7m1LCuXJUri8+5XDjrijQ5Xip1CQhdaXGUvUnmQqjXffUiL+V6d2OnkrVg== X-Received: by 2002:a1c:f50a:: with SMTP id t10mr2421566wmh.86.1559224267185; Thu, 30 May 2019 06:51:07 -0700 (PDT) Received: from vitty.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id f2sm3815143wrq.48.2019.05.30.06.51.06 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 30 May 2019 06:51:06 -0700 (PDT) From: Vitaly Kuznetsov To: Michael Kelley Cc: "catalin.marinas\@arm.com" , "mark.rutland\@arm.com" , "will.deacon\@arm.com" , "marc.zyngier\@arm.com" , "linux-arm-kernel\@lists.infradead.org" , "gregkh\@linuxfoundation.org" , "linux-kernel\@vger.kernel.org" , "linux-hyperv\@vger.kernel.org" , "olaf\@aepfle.de" , "apw\@canonical.com" , "jasowang\@redhat.com" , "marcelo.cerri\@canonical.com" , Sunil Muthuswamy , KY Srinivasan Subject: RE: [PATCH v3 2/2] Drivers: hv: Move Hyper-V clocksource code to new clocksource driver In-Reply-To: References: <1558969089-13204-1-git-send-email-mikelley@microsoft.com> <1558969089-13204-3-git-send-email-mikelley@microsoft.com> <87r28gl1d1.fsf@vitty.brq.redhat.com> Date: Thu, 30 May 2019 15:51:05 +0200 Message-ID: <87imtskq46.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michael Kelley writes: > From: Vitaly Kuznetsov Sent: Thursday, May 30, 2019 2:48 AM >> > + /* >> > + * sched_clock_register is needed on ARM64 but >> > + * is a no-op on x86 >> > + */ >> > + sched_clock_register(read_hv_sched_clock_msr, >> > + 64, HV_CLOCK_HZ); >> >> I'm not sure about ARM, but MSR-based clocksource would be a really bad >> choice for sched clock on x86, this will slow things down >> significantly. Luckily, as you're validly stating above, >> sched_clock_register() is a no-op on x86 as we don't define >> CONFIG_GENERIC_SCHED_CLOCK. >> >> Can we actually *not* do sched_clock_register() in case >> TSC page is unavailable (and revert to counting jiffies or whatever)? >> > > We can't skip the sched_clock_register() on ARM64 because it > does define CONFIG_GENERIC_SCHED_CLOCK. However, Hyper-V > should always provide REFERENCE_TSC_AVAILALBE on ARM64, > so we should never end up in the MSR-based code on ARM64. > Arguably that means the call to sched_clock_register() could be > removed since it's a no-op on x86. But I'd like to keep it for symmetry > and in case there's a testing/debugging situation on ARM64 where > we want to clear REFERENCE_TSC_AVAILABLE and go down the > MSR-based code path. Ok, so it is just a fall-back and not going to be actively used. Thanks! -- Vitaly