On Wed, Jun 19, 2019 at 10:57 PM Arnd Bergmann <a...@arndb.de> wrote: > > On Wed, Jun 19, 2019 at 10:07 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > > > On Wed, Jun 19, 2019 at 10:02 PM Arnd Bergmann <a...@arndb.de> wrote: > > > > 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. > > > > > > I would prefer not to add the new interface then. We might in > > > fact move users of get_jiffies_64() to ktime_get_coarse() for > > > consistency given the small overhead of that function. > > > > In light of the measurements, that seems like a good plan to me. > > > > One thing to consider with moving jiffies users over that way is > > ktime_t. Do you want to introduce helpers like > > ktime_get_boot_coarse_ns(), just like there is already with the other > > various functions like ktime_get_boot_ns(), ktime_get_boot_fast_ns(), > > etc? (I'd personally prefer using the _ns variants, at least.) I can > > send a patch for this. > > That sounds reasonable, but then I think we should have the full > set of coarse_*_ns() functions, again for consistency: > > u64 ktime_get_coarse_ns(void) > u64 ktime_get_coarse_boottime_ns(void) > u64 ktime_get_coarse_real_ns(void) > u64 ktime_get_coarse_clocktai_ns(void) > > and document them in Documentation/core-api/timekeeping.rst. > > We seem to also be lacking the basic ktime_get_coarse(), which > seems like a major omission. > Both ktime_get_coarse_ns and ktime_get_coarse can be wrappers > around ktime_get_coarse_ts64() then, while the others would > use ktime_get_coarse_with_offset().
Exactly what I had in mind. I'll have something posted fairly soon. Jason
