Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1238045ybl; Fri, 10 Jan 2020 14:43:24 -0800 (PST) X-Google-Smtp-Source: APXvYqyPBm8hiYtI0yaECkrwbTTwbQ2tqs5IZr70+CHO20z+WeSBzsbgeTgBJrSpIjT55NtqD4uS X-Received: by 2002:aca:f20b:: with SMTP id q11mr3929211oih.78.1578696204688; Fri, 10 Jan 2020 14:43:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578696204; cv=none; d=google.com; s=arc-20160816; b=mBWvyJCFpqzt6f7sQGUsOhkCtUoSx8lUP/z7zORo5LIVEvvylvYRx3WajhxtuHXp1q TkFEnVR8QfQjzWiztwhKeQ3KfabA6C7LI/WJT/h/6TAqZmfNy3Qtazus+xDC1iecJJr3 LyKMlLu8GvvboJSjBLTYZiayfRzUqE48w9v10u1ll0eTLPjdPdC5r8qJCsHgupoeyHKS WvbYwA87Zqk4pNlmYZi4gy1I2F4zqZVSU90R0+XTF8cLgGWm6H4C2m5DhWBXs/D6TbKL pJgXSYUVHL5T3or7pyYrdB3v3l8HzbDWSfA01eBGAp5BjIC00nTwXMBBEWwKUlkxqk/1 7h0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=bbcLoKMx/xKebwtiv/1/sLGqJqSde8o7UwQJy3CwRps=; b=WCFhfanC1fIaQdlMu5VE7sexx90mV6Ptgigu6RiYyXr0KsZU+IuADRi9T/Mt4UkMb9 ipoUMx8OqXbow+WG+HmcgR9sd1HYrPDeNbakScNOjS/rYhM98svI6qeKB0nFxav1XDSk PCu0xF8gn9qsCnhBh7mvQf94qeXbjvZ8WwUL9frgauogFKLJSbm1wo+fvoMKRxTke1yf f1H0v0/Zt6QXV5AuFqrBZqv7wox/KnOkG65eivv+mPf97SO4DCy/u425gHxD02t7URqY wft10z7w4LxPYohfwtM3LutsQgBmZGWq0GOxNROordgujMXs9ypgTo8VQ/7YqtARH/jS F4bg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w1si1926866oia.169.2020.01.10.14.43.12; Fri, 10 Jan 2020 14:43:24 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727446AbgAJWmQ (ORCPT + 99 others); Fri, 10 Jan 2020 17:42:16 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:60029 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727299AbgAJWmQ (ORCPT ); Fri, 10 Jan 2020 17:42:16 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iq2yj-0006Fk-RI; Fri, 10 Jan 2020 23:42:05 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 3A41A105BDB; Fri, 10 Jan 2020 23:42:05 +0100 (CET) From: Thomas Gleixner To: Christophe Leroy Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , vincenzo.frascino@arm.com, luto@kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation. In-Reply-To: <09d07ad3-47a2-db2f-2f14-e002b22d8d9e@c-s.fr> References: <8ce3582f7f7da9ff0286ced857e5aa2e5ae6746e.1571662378.git.christophe.leroy@c-s.fr> <95bd2367-8edc-29db-faa3-7729661e05f2@c-s.fr> <439bce37-9c2c-2afe-9c9e-2f500472f9f8@c-s.fr> <207cef10-3da8-6a52-139c-0620b21b64af@c-s.fr> <87d0bslo7b.fsf@nanos.tec.linutronix.de> <09d07ad3-47a2-db2f-2f14-e002b22d8d9e@c-s.fr> Date: Fri, 10 Jan 2020 23:42:05 +0100 Message-ID: <87h813rl1e.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe, Christophe Leroy writes: > On 01/09/2020 02:05 PM, Thomas Gleixner wrote: >> The reason why this is implemented in this way is that >> __arch_get_hw_counter() needs a way to express that the clocksource of >> the moment is not suitable for VDSO so that the syscall fallback gets >> invoked. >> >> Sure we could have used a pointer for the value and a return value >> indicating the validity, but given the required uptime the resulting >> code overhead seemed to be not worth it. At least not for me as I'm not >> planning to be around 58 years from now :) >> > > I managed to get better code and better performance by splitting out the > validity check as follows. Would it be suitable for all arches ? A quick test on x86 shows only a minimal impact, but it's in the noise. So from my side that's fine, but I can't talk for ARM[64]/MIPS > diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h > b/arch/powerpc/include/asm/vdso/gettimeofday.h > index 689f51b0d8c9..11cdd6faa4ad 100644 > --- a/arch/powerpc/include/asm/vdso/gettimeofday.h > +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h > @@ -114,15 +114,17 @@ int clock_getres32_fallback(clockid_t _clkid, > struct old_timespec32 *_ts) > return ret; > } > > -static __always_inline u64 __arch_get_hw_counter(s32 clock_mode) > +static __always_inline bool __arch_is_hw_counter_valid(s32 clock_mode) > { > /* > * clock_mode == 0 implies that vDSO are enabled otherwise > * fallback on syscall. > */ > - if (clock_mode) > - return ULLONG_MAX; > + return clock_mode ? false : true; I don't think we need an arch specific function here. I rather convert the boolean of ARM[64] to the x86/MIPS way of VCLOCK_* modes and let the generic code check for clock_mode == VCLOCK_NONE. There is some magic in ARM and MIPS which wants to be able to disable the whole thing at compile time, but that can be handled in the generic code with just an extra config switch. I'll have a stab at that tomorrow. Thanks, tglx