From: Arnd Bergmann <arnd@arndb.de>
To: Ed Cashin <ed.cashin@acm.org>
Cc: y2038@lists.linaro.org, Tina Ruchandani <ruchandani.tina@gmail.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [Y2038] [PATCH] aoe: Use 64-bit timestamp in frame
Date: Wed, 13 May 2015 10:04:26 +0200
Message-ID: <8535976.TAdvFKB2bQ@wuerfel>
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <5552A778.6070603@acm.org>
References: <20150511023505.GA2714@tinar> <2349651.fBUtehr528@wuerfel> <5552A778.6070603@acm.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2937
Lines: 62

On Tuesday 12 May 2015 21:23:04 Ed Cashin wrote:
> 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.

Shall we do the ktime_get_us() approach then? It still requires a 
32-bit division like do_gettimeofday(), so it will not be as efficient
as the shifted nanoseconds.

As for the aoe_deadsecs computation, converting the aoe_deadsec
module parameter into scaled nanoseconds can be done at module
load time, and that way you also save the integer division you
currently do for each frame in rexmit_timer() to turn the
microseconds into seconds.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/