From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965107AbbEMB34 (ORCPT ); Tue, 12 May 2015 21:29:56 -0400 Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]:50269 "HELO gproxy8-pub.mail.unifiedlayer.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S964834AbbEMB3z (ORCPT ); Tue, 12 May 2015 21:29:55 -0400 X-Greylist: delayed 399 seconds by postgrey-1.27 at vger.kernel.org; Tue, 12 May 2015 21:29:55 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=FurB0epzNeMA:10 a=N659UExz7-8A:10 a=N54-gffFAAAA:8 a=05RPwmwRPNYA:10 a=I4ko-sDDNxYA:10 a=h1PgugrvaO0A:10 a=_xoU9kyHp8h-vIEXsfQA:9 a=pILNOxqGKmIA:10 Message-ID: <5552A778.6070603@acm.org> Date: Tue, 12 May 2015 21:23:04 -0400 From: Ed Cashin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Arnd Bergmann , y2038@lists.linaro.org CC: Tina Ruchandani , linux-kernel@vger.kernel.org Subject: Re: [Y2038] [PATCH] aoe: Use 64-bit timestamp in frame References: <20150511023505.GA2714@tinar> <555150A9.8000301@acm.org> <2498255.lB0xaQWuiu@wuerfel> <2349651.fBUtehr528@wuerfel> In-Reply-To: <2349651.fBUtehr528@wuerfel> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {2969:box320.bluehost.com:cashinwo:cashinworks.com} {sentby:smtp auth 98.192.52.118 authed with ed@cashinworks.com} Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/12/2015 07:14 AM, Arnd Bergmann wrote: > On Tuesday 12 May 2015 11:44:21 Arnd Bergmann wrote: >> There are of course multiple ways to do this. One way would be to >> change the code to work on 32-bit nanoseconds instead of 32-bit >> microseconds. This requires proving that the we cannot exceed >> 4.29 seconds of round-trip time in calc_rttavg(). >> Is that a valid assumption or not? >> >> If not, we could replace do_gettimeofday() with ktime_get_ts64(). >> This will ensure we don't need a 64-bit division when converting >> the ts64 to a 32-bit microsecond value, and combined with the >> conversion is still no slower than do_gettimeofday(), and it >> still avoids the double bookkeeping because it uses a monotonic >> timebase that is robust against settimeofday. > Two other approaches that occurred to me later: > > - introduce common ktime_get_ms(), ktime_get_us(), ktime_get_real_ms() > and ktime_get_real_is() interfaces, to match the other interfaces > we already provide. These could be done as efficiently or better > than what aoe does manually today. > > - change the timebase that is used for the computations in aoe to use > scaled nanoseconds instead of microseconds. Using > > u32 time = ktime_get_ns() >> 10; > > would give you a similar range and precision as microseconds, but > completely avoid integer division. You could also use a different > shift value to either extend the range beyond 71 minutes, or the > extend the precision to something below a microsecond. This would > be the most efficient implementation, but also require significant > changes to the driver. > That is an interesting idea. People do care about aoe_deadsecs being pretty accurate, so there would need to be a way to make that remain accurate. The driver will fail outstanding I/O to the target and mark it as "down" after unsuccessfully retransmitting commands to the target for a number of seconds equal to aoe_deadsecs. As to the efficient ktime_get_us idea, that sounds appealing since you mention that they would be efficient. Thanks for the analysis. -- Ed