Received: by 10.213.65.68 with SMTP id h4csp47524imn; Thu, 15 Mar 2018 09:08:29 -0700 (PDT) X-Google-Smtp-Source: AG47ELs3Qtf2hMgW+4XghrhMsgF3XHYMyuadC3S81dgSzJHINRpa1wSZRu6hCfFbb0eRJHj9L2pC X-Received: by 2002:a17:902:5501:: with SMTP id f1-v6mr7318600pli.50.1521130109122; Thu, 15 Mar 2018 09:08:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521130109; cv=none; d=google.com; s=arc-20160816; b=KW4cYFeA1JMmSpkafYmJnZiqPIMuToaFPM9NHMleYdejE/ChggLF54Ub2bh8Z8RTvw axF0x0V2SKXTKgOmyFBX2FN/af1waak0ffarZ+AR3VIAtKwjxDRMTCMLP7H99r17G8tp HcuMpr3vwjQk2t/wDQRndIFu6S1USRRlwhuSzSGa5aZZn6AoX9WRR9EF3DV8+bF76sy0 52MV5sELN8ayCzkusjvitgg7Nz2FV8u+3BK9GeyHn5Ht5tJHh3ahXsGu6iDGLF0oO9uA PN3umWCjZR2cH2RN8ii88cPv1vPwcd6MQKGDUxsoTRmQXnBHRjpDGcQR/QBbb7FBynFv 1Z4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=JqrZPiRSUzqpv1etuN+SfwRKYVcq1gi9ndYgDWobnPg=; b=IqWqGDSw/6IOinbxMNYTkLgLAg/InPY46zokVv6oARvU9K3cph+xYZrHG1RsASEbgW oGCCh2AbVOlJB2kn8GC9BW5etzbykFTHlVFUpXDk0jTZAj2l/+Yot1hXKdSvJcETqkCs tCNPXmSktOv7iXSufFHWvNKz0rFeiWOZxmXIEiwjy5B3JeKySfV7BVWMAfK4+0PN4uD4 kSvasCBsxQiirARNyu4Vev6NeQr3X2ULXUwp4xW40c6TRU02YcCq5eAWiL3I8lYSOfnq X+bE55MDbMd+9djjI1JNjYPcHn1SZQBfg9vGbU79RZHJpfk954cw8SvdK4nce6vielQT v1gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=saBEydwS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s4si3952271pfg.410.2018.03.15.09.08.14; Thu, 15 Mar 2018 09:08:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=saBEydwS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933019AbeCOQGH (ORCPT + 99 others); Thu, 15 Mar 2018 12:06:07 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:53789 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932899AbeCOQA7 (ORCPT ); Thu, 15 Mar 2018 12:00:59 -0400 Received: by mail-wm0-f67.google.com with SMTP id e194so11395795wmd.3 for ; Thu, 15 Mar 2018 09:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=JqrZPiRSUzqpv1etuN+SfwRKYVcq1gi9ndYgDWobnPg=; b=saBEydwSyrPGxgNdqqcM4li4dEiIkl+YNnILyuSD/rAwj7EXBse050UjMC/C67CdCE APnck06j7JzfWcQkoa+vuywWajyOwDQvE1/3Bic+Z0z9SN5cpCNDbUyR9YxqY+OR98sp 6a1ejDjrTq0HlnhcQT/S53WpFcNOb8xPIFxeADCbVzR7jj7oEDPw07VJX07ejE6F2pmX zNecrMJGUz8yNcUV1kjC6MJJ2xiHiP056/IKXGn5l8rQTlUa0mdsKjpdp7Zh4iCMJYHO IM2N36aHztVfKmDEcmYXEww53K+yn8ftIb1igSmgIaJBMPB72tgtiHpPVm8qHPvPqahJ vbOg== 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:date:message-id; bh=JqrZPiRSUzqpv1etuN+SfwRKYVcq1gi9ndYgDWobnPg=; b=UO6nyoLWGgt8htnLcKtMHSBRIrEuxIq6dbiL20jE9IaZhc5fYtPnzpy4fAOsahvD7r ybSqRW3f8OD9BVf2SKfXv+wldBhBks8ZTc8jUJFq/9rP5hACha0ynN0ZBrXt1WNfnD6f wQMsGZFO+JuF+/RU3i6Snkn/XGVT1bTt4M66ivDqR6mXAyKF78/crb8RFoWGm5wknXs5 HPQxOgPIQ31zdvqArQvd9kzHf2GC4Am1QbwN10ImFsWWMWoyE+hhax0dsta0o7jkp07E AEy7EUP5Dn960kP/kTf7oeVk/2ab6BX/uZ9AA8g6wjVKP7COYPfcRdOolIEEtCFOquZI wkqw== X-Gm-Message-State: AElRT7EIYqjmGoI2FEsSQfxTYdT9HkElyTS5nhaDYr+y19o1a0HFOEgu IOxi4VEPXdqrgzgOSLT2nhOn5dgn X-Received: by 10.80.187.75 with SMTP id y69mr9584694ede.251.1521129657364; Thu, 15 Mar 2018 09:00:57 -0700 (PDT) Received: from localhost.localdomain ([83.147.149.202]) by smtp.gmail.com with ESMTPSA id z7sm2508306edb.46.2018.03.15.09.00.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Mar 2018 09:00:56 -0700 (PDT) From: jason.vas.dias@gmail.com To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, tglx@linutronix.de, mingo@kernel.org, peterz@infradead.org, andi@firstfloor.org Subject: [PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW Date: Thu, 15 Mar 2018 16:00:45 +0000 Message-Id: <1521129648-20889-1-git-send-email-jason.vas.dias@gmail.com> X-Mailer: git-send-email 2.8.2 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Resent to address reviewer comments. Currently, the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, &ts ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2 2.8-3.9ghz Haswell x86_64 Family'_'Model : 06_3C machines under various versions of Linux. Sometimes, particularly when correlating elapsed time to performance counter values, user-space code needs to know elapsed time from the perspective of the CPU no matter how "hot" / fast or "cold" / slow it might be running wrt NTP / PTP "real" time; when code needs this, the latencies associated with a syscall are often unacceptably high. I reported this as Bug #198161 : 'https://bugzilla.kernel.org/show_bug.cgi?id=198961' and in previous posts with subjects matching 'CLOCK_MONOTONIC_RAW' . This patch handles CLOCK_MONOTONIC_RAW clock_gettime() in the VDSO , by exporting the raw clock calibration, last cycles, last xtime_nsec, and last raw_sec value in the vsyscall_gtod_data during vsyscall_update() . Now the new do_monotonic_raw() function in the vDSO has a latency of @ 24ns on average, and the test program: tools/testing/selftest/timers/inconsistency-check.c succeeds with arguments: '-c 4 -t 120' or any arbitrary -t value. The patch is against Linus' latest 4.16-rc5 tree, current HEAD of : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . This patch affects only files: arch/x86/include/asm/vgtod.h arch/x86/entry/vdso/vclock_gettime.c arch/x86/entry/vdso/vdso.lds.S arch/x86/entry/vdso/vdsox32.lds.S arch/x86/entry/vdso/vdso32/vdso32.lds.S arch/x86/entry/vsyscall/vsyscall_gtod.c There are 3 patches in the series : Patch #1 makes the VDSO handle clock_gettime(CLOCK_MONOTONIC_RAW) with rdtsc_ordered() Patches #2 & #3 should be considered "optional" : Patch #2 makes the VDSO handle clock_gettime(CLOCK_MONOTONIC_RAW) with a new rdtscp() function in msr.h Patch #3 makes the VDSO export TSC calibration data via a new function in the vDSO: unsigned int __vdso_linux_tsc_calibration ( struct linux_tsc_calibration *tsc_cal ) that user code can optionally call. Patch #2 makes clock_gettime(CLOCK_MONOTONIC_RAW) calls somewhat faster than clock_gettime(CLOCK_MONOTONIC) calls. I think something like Patch #3 is necessary to export TSC calibration data to user-space TSC readers. It is entirely up to the kernel developers whether they want to include patches #2 and #3, but I think something like Patch #1 really needs to get into a future Linux release, as an unecessary latency of 200-1000ns for a timer that can tick 3 times per nanosecond is unacceptable. Patches for kernels 3.10.0-21 and 4.9.65-rt23 (ARM) are attached to bug #198161. Thanks & Best Regards, Jason Vas Dias