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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 52453C3A59E for ; Wed, 21 Aug 2019 08:54:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2C8082339E for ; Wed, 21 Aug 2019 08:54:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726762AbfHUIyd (ORCPT ); Wed, 21 Aug 2019 04:54:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38564 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbfHUIyc (ORCPT ); Wed, 21 Aug 2019 04:54:32 -0400 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1405B3C934 for ; Wed, 21 Aug 2019 08:54:32 +0000 (UTC) Received: by mail-wr1-f71.google.com with SMTP id w11so902841wru.17 for ; Wed, 21 Aug 2019 01:54:32 -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=+w6S/d4xE8RPcCnUmNNhlmM38FUwU6Cbxaxoa0JXU/s=; b=NL/vbCMMffTvbH8RxJVgicZ35DCHLPwVv65+CG4ckf+U91oRhC/q4RieKmW6RhBLVD npZSgf+ouC0Z4QL07j6LHwanACxol++zc69kUjXz7fENpxIrGnJ5Q9cI1vyNicknbEmQ WfHoCnE1FQj5DtvTrrMWlBU8DxAR5EREPz2xlX1OVOnU2UL1PQ30gbwhgCGzw1UwrvwG x2ysyRg6ee3OKRc2fonNPeebHexfiyd0TLpLWRoDd7nbG0V1oV86xK9KHrnPGqL8lXZw T73QNo2VE8+FdfKIgtGnRU4VWDJXkAqWwhj+gPPxnTc01oW65nn0gfQ24BYBkuhuXCTD MdpQ== X-Gm-Message-State: APjAAAXEQvOBCCLw3Vkl9VPWd5/7TBlOwPhRvIzQM3jPgkZoNcWkJGWQ CrCU5MLQRbkMZa6bNnEB0GmgMY9QdcWIuFhoEhZsxTLp6TeX/faLDGw9lckhwxI1EUgHO4QF854 f8oWV8M29R+tO/IuW8lUwEk/s X-Received: by 2002:a1c:9d8c:: with SMTP id g134mr4872145wme.174.1566377670688; Wed, 21 Aug 2019 01:54:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqwJvqD1cl28+sp4QHLw+FNqBWCQTObXkxuvx4NlL/0iLvU5iNtqQtOMuGgDZJYc9msHKi9j9A== X-Received: by 2002:a1c:9d8c:: with SMTP id g134mr4872098wme.174.1566377670394; Wed, 21 Aug 2019 01:54:30 -0700 (PDT) Received: from vitty.brq.redhat.com (ip-89-176-161-20.net.upcbroadband.cz. [89.176.161.20]) by smtp.gmail.com with ESMTPSA id m23sm3103680wml.41.2019.08.21.01.54.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Aug 2019 01:54:29 -0700 (PDT) From: Vitaly Kuznetsov To: Michael Kelley , Tianyu Lan Cc: Peter Zijlstra , Tianyu Lan , "linux-arch\@vger.kernel.org" , "linux-hyperv\@vger.kernel.org" , "linux-kernel\@vger kernel org" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , the arch/x86 maintainers , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Sasha Levin , Daniel Lezcano , Arnd Bergmann Subject: RE: [PATCH 0/2] clocksource/Hyper-V: Add Hyper-V specific sched clock function In-Reply-To: <87o90jq99w.fsf@vitty.brq.redhat.com> References: <20190729075243.22745-1-Tianyu.Lan@microsoft.com> <87zhkxksxd.fsf@vitty.brq.redhat.com> <20190729110927.GC31398@hirez.programming.kicks-ass.net> <87wog1kpib.fsf@vitty.brq.redhat.com> <87sgq5a2hq.fsf@vitty.brq.redhat.com> <87o90jq99w.fsf@vitty.brq.redhat.com> Date: Wed, 21 Aug 2019 10:54:28 +0200 Message-ID: <87imqqrj97.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-hyperv-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org Vitaly Kuznetsov writes: > Michael Kelley writes: > >> I talked to KY Srinivasan for any history about TSC page on 32-bit. He said >> there was no technical reason not to implement it, but our focus was always >> 64-bit Linux, so the 32-bit was much less important. Also, on 32-bit Linux, >> the required 64x64 multiply and shift is more complex and takes more >> more cycles (compare 32-bit implementation of mul_u64_u64_shr vs. >> the 64-bit implementation), so the win over a MSR read is less. I >> don't know of any actual measurements being made to compare vs. >> MSR read. > > VMExit is 1000 CPU cycles or so, I would guess that TSC page > calculations are better. Let me try to build 32bit kernel and do some > quick measurements. So I tried and the difference is HUGE. For in-kernel clocksource reads (like sched_clock()), the testing code was: before = rdtsc_ordered(); for (i = 0; i < 1000; i++) (void)read_hv_sched_clock_msr(); after = rdtsc_ordered(); printk("MSR based clocksource: %d cycles\n", ((u32)(after - before))/1000); before = rdtsc_ordered(); for (i = 0; i < 1000; i++) (void)read_hv_sched_clock_tsc(); after = rdtsc_ordered(); printk("TSC page clocksource: %d cycles\n", ((u32)(after - before))/1000); The result (WS2016) is: [ 1.101910] MSR based clocksource: 3361 cycles [ 1.105224] TSC page clocksource: 49 cycles For userspace reads the absolute difference is even bigger as TSC page gives us functional vDSO: Testing code: before = rdtsc(); for (i = 0; i < COUNT; i++) clock_gettime(CLOCK_REALTIME, &tp); after = rdtsc(); printf("%d\n", (after - before)/COUNT); Result: TSC page: # ./gettime_cycles 131 MSR: # ./gettime_cycles 5664 With all that I see no reason for us to not enable TSC page on 32bit, even if the number of users is negligible, this will allow us to get rid of ugly #ifdef CONFIG_HYPERV_TSCPAGE in the code. I'll send a patch for discussion. -- Vitaly