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;
Subject: Re: [PATCH] [RESEND] aoe: use ktime_t instead of timeval
To:     Arnd Bergmann <arnd@arndb.de>, "Ed L. Cashin" <ed.cashin@acm.org>
Cc:     Tina Ruchandani <ruchandani.tina@gmail.com>,
        linux-kernel@vger.kernel.org
References: <20180117153052.3831762-1-arnd@arndb.de>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <7b4d1840-103f-dfb8-3918-678fdc93d816@kernel.dk>
Date:   Wed, 17 Jan 2018 08:41:42 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101
 Thunderbird/58.0
MIME-Version: 1.0
In-Reply-To: <20180117153052.3831762-1-arnd@arndb.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 1/17/18 8:30 AM, Arnd Bergmann wrote:
> From: Tina Ruchandani <ruchandani.tina@gmail.com>
> 
> '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' is deprecated because it 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 the recommended type for timestamping
> - 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.
> 
> [updates by Arnd below]
> The original patch from Tina never went anywhere as we discussed how
> to keep the impact on performance minimal. I've started over now but
> arrived at basically the same patch that she had originally, except for
> an slightly improved tsince_hr() function. I'm making it more robust
> against overflows, and also optimize explicitly for the common case
> in which a frame is less than 4.2 seconds old, using only a 32-bit
> division in that case.
> 
> This should make the new version more efficient than the old code,
> since we replace the existing two 32-bit division in do_gettimeofday()
> plus one multiplication with a single single 32-bit division in
> tsince_hr() and drop the double bookkeeping. It's also more efficient
> than the ktime_get_us() API we discussed before, since that would
> also rely on multiple divisions.

Applied, thanks Arnd/Tina.

-- 
Jens Axboe