在 2021/9/29 下午7:37, Pavel Begunkov 写道:

On 9/29/21 10:24 AM, Hao Xu wrote:

quoted

在 2021/9/28 下午6:51, Pavel Begunkov 写道:

quoted

On 9/26/21 11:00 AM, Hao Xu wrote:

[...]

quoted

quoted

quoted

I'm gonna pick this one up again, currently this patch
with ktime_get_ns() works good on our productions. This
patch makes the latency a bit higher than before, but
still lower than aio.
I haven't gotten a faster alternate for ktime_get_ns(),
any hints?

Good, I'd suggest to look through Documentation/core-api/timekeeping.rst
In particular coarse variants may be of interest.
https://www.kernel.org/doc/html/latest/core-api/timekeeping.html#coarse-and-fast-ns-access

The coarse functions seems to be like jiffies, because they use the last
timer tick(from the explanation in that doc, it seems the timer tick is
in the same frequency as jiffies update). So I believe it is just
another format of jiffies which is low accurate.

I haven't looked into the details, but it seems that unlike jiffies for
the coarse mode 10ms (or whatever) is the worst case, but it _may_ be

Maybe I'm wrong, but for jiffies, 10ms uis also the worst case, no?
(say HZ = 100, then jiffies updated by 1 every 10ms)

much better on average and feasible for your case, but can't predict
if that's really the case in a real system and what will be the
relative error comparing to normal ktime_ns().