Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4785574ybg; Mon, 21 Oct 2019 14:32:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqzhNFIiPhw+yq/3aLPOJ9+tFeo0wFRJKBXYabOpkcy+PN+nw7Gh2+qO980IW5BpLkOVVG4I X-Received: by 2002:a17:906:743:: with SMTP id z3mr841162ejb.142.1571693531627; Mon, 21 Oct 2019 14:32:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571693531; cv=none; d=google.com; s=arc-20160816; b=vG44rIjADcByN6BNiObx9zpYRWFq1GoXAj6A8/CaEiYnMz93jZzmix8VO1OIKcElSD pFqRuCEZDk/RS3cQL+h93iMzgqxcaY8U0e8i5keGuBuqIAGzfxY5kiucmgPHqvPiDiWj uUMWTjhgG+q3eXnbuP3wUj6NMF71MzJZjDL5ADsjx1rcloZ+pbvXagRWXqZTg3vvIgkn 6sW7lV4REdJ2/8SMxcZOT+mEuOo8gMySwS9RoUj/c4XC+0nqAykphVH9ShOlQpNoOzgm Lqqzk9l1pPlHSYFtONopI/mcdhyz1LFVnhFxDiBXcqQKgk5Pbs5cLVu99GoQa55ZQjo7 lPFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=y5UtKrARuFOCKMstv7d+9jhEkdGMdM5qm3LHWQ2HxAA=; b=xabtp4omcguNbGAAyA4STDmj9Orn9t9sP3+h+jQbExUQk1I1/vonihahPqWoKiudjE hSOrN8g3hNQFn1JSyRUGEuYJZVV56c/u0435Zq9TtBAAmf9cYhCu0dc3BgRbpUZ2SB+L hzlq5qme5kXSIa5qfu7Rl8xbf6RCTrSUA69551w2Qo4T4QaYVfJiZX2CX/MKvWQpmLK7 uV5N0jdUF58az9vaWbB3brJuaVRlUDRxw1FJuy7CGqEONauX1s/wGvyy7Znug0GzoHu8 lQ1yFoqtbLbs1ngFNOWQGrX/zLqraz/SMRX3BG7MeUa2nswnD6lrlz6AXhik4aK7ZeUz teMg== 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 f13si10573203ejj.402.2019.10.21.14.31.46; Mon, 21 Oct 2019 14:32:11 -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; 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 S1730388AbfJUV3Z (ORCPT + 99 others); Mon, 21 Oct 2019 17:29:25 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:37779 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728943AbfJUV3Z (ORCPT ); Mon, 21 Oct 2019 17:29:25 -0400 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iMfEg-0002d0-Qs; Mon, 21 Oct 2019 23:29:06 +0200 Date: Mon, 21 Oct 2019 23:29:05 +0200 (CEST) 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: <8ce3582f7f7da9ff0286ced857e5aa2e5ae6746e.1571662378.git.christophe.leroy@c-s.fr> Message-ID: References: <8ce3582f7f7da9ff0286ced857e5aa2e5ae6746e.1571662378.git.christophe.leroy@c-s.fr> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 On Mon, 21 Oct 2019, Christophe Leroy wrote: > This is a tentative to switch powerpc/32 vdso to generic C implementation. > It will likely not work on 64 bits or even build properly at the moment. > > powerpc is a bit special for VDSO as well as system calls in the > way that it requires setting CR SO bit which cannot be done in C. > Therefore, entry/exit and fallback needs to be performed in ASM. > > To allow that, C fallbacks just return -1 and the ASM entry point > performs the system call when the C function returns -1. > > The performance is rather disappoiting. That's most likely all > calculation in the C implementation are based on 64 bits math and > converted to 32 bits at the very end. I guess C implementation should > use 32 bits math like the assembly VDSO does as of today. > gettimeofday: vdso: 750 nsec/call > > gettimeofday: vdso: 1533 nsec/call The only real 64bit math which can matter is the 64bit * 32bit multiply, i.e. static __always_inline u64 vdso_calc_delta(u64 cycles, u64 last, u64 mask, u32 mult) { return ((cycles - last) & mask) * mult; } Everything else is trivial add/sub/shift, which should be roughly the same in ASM. Can you try to replace that with: static __always_inline u64 vdso_calc_delta(u64 cycles, u64 last, u64 mask, u32 mult) { u64 ret, delta = ((cycles - last) & mask); u32 dh, dl; dl = delta; dh = delta >> 32; res = mul_u32_u32(al, mul); if (ah) res += mul_u32_u32(ah, mul) << 32; return res; } That's pretty much what __do_get_tspec does in ASM. Thanks, tglx