From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932388AbcLIGi7 (ORCPT ); Fri, 9 Dec 2016 01:38:59 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:42765 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752847AbcLIGi6 (ORCPT ); Fri, 9 Dec 2016 01:38:58 -0500 Date: Fri, 9 Dec 2016 07:38:47 +0100 From: Peter Zijlstra To: Thomas Gleixner Cc: LKML , John Stultz , Ingo Molnar , David Gibson , Liav Rehana , Chris Metcalf , Richard Cochran , Parit Bhargava , Laurent Vivier , "Christopher S. Hall" Subject: Re: [patch 5/6] [RFD] timekeeping: Provide optional 128bit math Message-ID: <20161209063847.GC15765@worktop.programming.kicks-ass.net> References: <20161208202623.883855034@linutronix.de> <20161208204229.005418487@linutronix.de> <20161209052638.GC3061@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161209052638.GC3061@worktop.programming.kicks-ass.net> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 09, 2016 at 06:26:38AM +0100, Peter Zijlstra wrote: > On Thu, Dec 08, 2016 at 08:49:39PM -0000, Thomas Gleixner wrote: > > > +static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr, u64 delta) > > +{ > > + u32 dh, dl; > > + u64 nsec; > > + > > + dl = delta; > > + dh = delta >> 32; > > + > > + nsec = ((u64)dl * tkr->mult) + tkr->xtime_nsec; > > + nsec >>= tkr->shift; > > + if (unlikely(dh)) > > + nsec += ((u64)dh * tkr->mult) << (32 - tkr->shift); > > + return nsec; > > +} > > Just for giggles, on tilegx the branch is actually slower than doing the > mult unconditionally. > > The problem is that the two multiplies would otherwise completely > pipeline, whereas with the conditional you serialize them. On my Haswell laptop the unconditional version is faster too. > (came to light while talking about why the mul_u64_u32_shr() fallback > didn't work right for them, which was a combination of the above issue > and the fact that their compiler 'lost' the fact that these are > 32x32->64 mults and did 64x64 ones instead). Turns out using GCC-6.2.1 we have the same problem on i386, GCC doesn't recognise the 32x32 mults and generates crap. This used to work :/