From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752220AbbEKQGB (ORCPT ); Mon, 11 May 2015 12:06:01 -0400 Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:40241 "HELO gproxy2-pub.mail.unifiedlayer.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750876AbbEKQF5 (ORCPT ); Mon, 11 May 2015 12:05:57 -0400 X-Greylist: delayed 400 seconds by postgrey-1.27 at vger.kernel.org; Mon, 11 May 2015 12:05:57 EDT X-Authority-Analysis: v=2.1 cv=Zox+dbLG c=1 sm=1 tr=0 a=6lV6tj8ir7tGSl/9xQZNPA==:117 a=6lV6tj8ir7tGSl/9xQZNPA==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=N54-gffFAAAA:8 a=n8i27M1mAAAA:8 a=05RPwmwRPNYA:10 a=Wf0FgBSChR0A:10 a=h1PgugrvaO0A:10 a=pGLkceISAAAA:8 a=PUPJTZ5Zd8LXMu-C6ScA:9 a=QEXdDO2ut3YA:10 Date: Mon, 11 May 2015 11:59:04 -0400 Subject: Re: [PATCH] aoe: Use 64-bit timestamp in frame Message-ID: <3cc42168-676a-49da-880f-aacd904e5b31@email.android.com> X-Android-Message-ID: <3cc42168-676a-49da-880f-aacd904e5b31@email.android.com> In-Reply-To: <2958316.132LBl1X80@wuerfel> From: Ed Cashin To: Arnd Bergmann Cc: linux-kernel@vger.kernel.org, y2038@lists.linaro.org, Tina Ruchandani MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Identified-User: {2969:box320.bluehost.com:cashinwo:cashinworks.com} {sentby:smtp auth 166.172.56.163 authed with ed@cashinworks.com} Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t4BG6AqD010035 I would like to see some performance measurements for this patch on a system with fast storage and multiple 10 GbE links. If not, at least a good analysis of the expected performance impact the patch will have on major architectures. Tonight I will think about whether the 2038 thing even matters or whether we just need a comment explaining why it's safe. On May 11, 2015 11:38 AM, Arnd Bergmann wrote: > > On Monday 11 May 2015 08:05:05 Tina Ruchandani wrote: > > 'struct frame' uses two variables to store the sent timestamp - 'struct > > timeval' and jiffies. jiffies is used to avoid discrepancies caused by > > updates to system time. 'struct timeval' uses 32-bit representation for > > seconds which will overflow in year 2038. > > This patch does the following: > > - Replace the use of 'struct timeval' and jiffies with ktime_t, which > > is a 64-bit timestamp and is year 2038 safe. > > - ktime_t provides both long range (like jiffies) and high resolution > > (like timeval). Using ktime_get (monotonic time) instead of wall-clock > > time prevents any discprepancies caused by updates to system time. > > > > Signed-off-by: Tina Ruchandani > > Very nice! > > > @@ -499,32 +497,15 @@ resend(struct aoedev *d, struct frame *f) > >  static int > >  tsince_hr(struct frame *f) > >  { > > - struct timeval now; > > + ktime_t now; > >  int n; > >  > > - do_gettimeofday(&now); > > - n = now.tv_usec - f->sent.tv_usec; > > - n += (now.tv_sec - f->sent.tv_sec) * USEC_PER_SEC; > > + now = ktime_get(); > > + n = ktime_to_us(ktime_sub(now, f->sent)); > >  > > I would cut four extra lines by writing this as > > return ktime_us_delta(ktime_get(), f->sent)); > > but the effect is exactly the same. > > With that change, please add > > Reviewed-by: Arnd Bergmann > > Arnd {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I