On 9/30/21 9:51 AM, Pavel Begunkov wrote:

On 9/29/21 1:13 PM, Hao Xu wrote:

quoted

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

quoted

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)

I'm speculating, but it sounds it's updated on every call to ktime_ns()
in the system, so if someone else calls ktime_ns() every 1us, than the
resolution will be 1us, where with jiffies the update interval is strictly
10ms when HZ=100. May be not true, need to see the code.

Taking a second quick look, doesn't seem to be the case indeed. And it's
limited to your feature anyway, so the overhead of ktime_get() shouldn't
matter much.

quoted

quoted

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().

-- 
Pavel Begunkov