[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9rYgKxNyLH4MFJwaj4188O5N6vjseQRHwF0n5pZhU8kuw@mail.gmail.com>
Date: Wed, 19 Jun 2019 17:31:04 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2] timekeeping: get_jiffies_boot_64() for jiffies that
include sleep time
Hi Arnd,
On Wed, Jun 19, 2019 at 5:08 PM Arnd Bergmann <arnd@...db.de> wrote:
> Can you quantify how much this gains you over ktime_get_coarse_boottime
> in practice? You are effectively adding yet another abstraction for time,
> which is something I'd hope to avoid unless you have a strong reason other
> than it being faster in theory.
Excellent idea. It turns out to be precisely 0 (see below). A
motivation still remains, though: this allows comparison with units
specified in terms of jiffies, which means that the unit being
compared matches the exact tick of the clock, making those comparisons
as precise as possible, for what they are. I suppose you could argue,
on the other hand, that nanoseconds give so much precision already,
that approximations using them amount practically to the same thing.
I'm not sure which way to reason about that.
For interest, here are a few comparisons taken with kbench9000:
get_jiffies_boot_64 26
ktime_get_coarse_boottime 26
ktime_get_boot_fast_ns with tsc 70
ktime_get_boot_fast_ns with hpet 4922
ktime_get_boot_fast_ns with acpi_pm 1884
As expected, hpet is really quite painful.
Jason
Powered by blists - more mailing lists