Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2138585ybl; Sat, 1 Feb 2020 14:31:25 -0800 (PST) X-Google-Smtp-Source: APXvYqwkXSxywVB33CLU9gnH3+YE7ambidxCF/gcq06LfjKQJaDEeGxz7HJocXWkeEpoOXo9B1YV X-Received: by 2002:aca:e146:: with SMTP id y67mr10121352oig.93.1580596285795; Sat, 01 Feb 2020 14:31:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580596285; cv=none; d=google.com; s=arc-20160816; b=wS68gsTnaw16601ePX78JC7uSPaFVlBKquxXzNVfX4qHcZ55zJxHbPv+5DZhbvWABn kVz7sM+FIsdmrooWlNxeey/ZhOFg0Rw4BJr7Afmsvvunp3K4c5Tk4Qi1bztCJzs/z7Xr oqe6z0NqMpPuuD5APIjWkBmY9jphfqB3xIEw4PqJo5UjimMiqFrh8keX8qkLmF6updfX gCblSfI0NCmlaVuNDwa6nRAw3ajgdV8U94ldjQRiLPkMQHHkGvFxE7de5yHBExuBzSlu jFoFsb6B6C3dgHbnONBRKqiB8syr8qwarwIybsdmKN8OdcJ4l5K2QCJ0I32RYjRvMEd8 5cyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date; bh=vshc3B23gqiV8clg+g711HtV520DAqyHTioit9wv3Uk=; b=G6ptx2MUv7dm+oefuqux/ajBKD5HUel8aBXGxdeEuxjGZJcmnFGCFGtY7LfhOTNiE/ faO+Jn437+a94Aj5o5QGUU3o26288jl8shZf9xIroKTX4pMGV3COWmTTy2PREfWoUrqc 5aoScniwFtI/XmCalHFCvRteh4/H6Ihzn27QKsE2siA6EWYlSZ+shwQsF+Pbmw3CY4tZ lwNiR0DWpyTGYYUlB6SiFIX/TL3FMGl14eHwq+5VkgoP5493XK31+MvNlKWAr48d8mFK nGcfbdSAZCkUfjrBzjhHvBFcCvleRsg7pdkGOlCLDzz8Yn7oj9zj2FqRqRRrg70n0t+M /RPA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 4si2549742oip.107.2020.02.01.14.31.12; Sat, 01 Feb 2020 14:31:25 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726643AbgBAWaN convert rfc822-to-8bit (ORCPT + 99 others); Sat, 1 Feb 2020 17:30:13 -0500 Received: from terminus.zytor.com ([198.137.202.136]:58457 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726487AbgBAWaM (ORCPT ); Sat, 1 Feb 2020 17:30:12 -0500 Received: from [IPv6:2601:646:8600:3281:fd34:ea1e:1509:a22b] ([IPv6:2601:646:8600:3281:fd34:ea1e:1509:a22b]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id 011MTi6D063624 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 1 Feb 2020 14:29:47 -0800 Date: Sat, 01 Feb 2020 14:29:35 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <20200130130838.29157-1-wenyang@linux.alibaba.com> References: <20200130130838.29157-1-wenyang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH] x86/tsc: improve arithmetic division To: Wen Yang , Thomas Gleixner , Borislav Petkov , Ingo Molnar CC: x86@kernel.org, linux-kernel@vger.kernel.org From: hpa@zytor.com Message-ID: <35AFFA5A-B499-4D64-9E98-42B9A642EB0F@zytor.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On January 30, 2020 5:08:38 AM PST, Wen Yang wrote: >do_div() does a 64-by-32 division. Use div64_ul64() or div64_ul() >instead of it if the divisor is 'ul64' or 'unsigned long', to avoid >truncation to lower 32-bit. >And as a nice side effect also cleans up the function a bit. > >Signed-off-by: Wen Yang >Cc: Thomas Gleixner >Cc: Ingo Molnar >Cc: Borislav Petkov >Cc: "H. Peter Anvin" >Cc: x86@kernel.org >Cc: linux-kernel@vger.kernel.org >--- > arch/x86/kernel/tsc.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > >diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c >index 7e322e2daaf5..4c0320e68699 100644 >--- a/arch/x86/kernel/tsc.c >+++ b/arch/x86/kernel/tsc.c >@@ -357,9 +357,7 @@ static unsigned long calc_pmtimer_ref(u64 deltatsc, >u64 pm1, u64 pm2) > pm2 -= pm1; > tmp = pm2 * 1000000000LL; > do_div(tmp, PMTMR_TICKS_PER_SEC); >- do_div(deltatsc, tmp); >- >- return (unsigned long) deltatsc; >+ return (unsigned long) div64_u64(deltatsc, tmp); > } > > #define CAL_MS 10 >@@ -778,8 +776,7 @@ static unsigned long >pit_hpet_ptimer_calibrate_cpu(void) > tsc_ref_min = min(tsc_ref_min, (unsigned long) tsc2); > > /* Check the reference deviation */ >- delta = ((u64) tsc_pit_min) * 100; >- do_div(delta, tsc_ref_min); >+ delta = div64_ul(((u64) tsc_pit_min) * 100, tsc_ref_min); > > /* > * If both calibration results are inside a 10% window This is a *lot* more expensive on 32 bits (something like 10x) and as the output is truncated to unsigned long anyway, it is also unnecessary. We don't use the remainder, so using do_div() is not merely unnecessary but almost certainly generates worse code: we are multiplying and then dividing by a constant, and most of the time gcc can optimize that into a single multiply/shift operation; otherwise we can do that optimization for it (see timeconst.bc.) The one thing that gcc can't necessary do automatically is to know when a 64/32 → 32 division is safe; C semantics are truncation, but the CPU will trap. If it can turn it into a multiply then that problem obviously goes away. So first I would test with regular / operators and see what code comes out. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.