linux-kernel - Re: hrtimer precision issue/question??

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJNi4rPtsUohpXgD28Bi7K4Y0G=ShgNuUmf1L3E4ze7txj_z0w@mail.gmail.com>
Date: Tue, 25 Mar 2025 17:54:58 +0800
From: richard clark <richard.xnu.clark@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	Linus Torvalds <torvalds@...ux-foundation.org>, richard clark <richard.xnu.clark@...il.com>
Subject: Re: hrtimer precision issue/question??

Hi tglx, Thanks for the explanation! I tried run 'cyclictest -a 0 -t 1
-m -p99 -r' to use the relative timer instead of absolute, now the
output of the same diff as:
[   63.824382] [ 0- 0]t0=63816686720,t1=63817689248,d=1002 us
[   63.825387] [ 0- 0]t0=63817691648,t1=63818694144,d=1002 us
[   63.825691] [ 4- 7]t0=63808939136,t1=63818998336,d=10059 us
[   63.826392] [ 0- 0]t0=63818696544,t1=63819699456,d=1002 us
[   63.827402] [ 0- 0]t0=63819704352,t1=63820709120,d=1004 us
[   63.828407] [ 0- 0]t0=63820712448,t1=63821714976,d=1002 us
[   63.829413] [ 0- 0]t0=63821717536,t1=63822720032,d=1002 us
[   63.830417] [ 0- 0]t0=63822722496,t1=63823724928,d=1002 us
[   63.831423] [ 0- 0]t0=63823727264,t1=63824730912,d=1003 us
[   63.832429] [ 0- 0]t0=63824734176,t1=63825736768,d=1002 us
[   63.833434] [ 0- 0]t0=63825739168,t1=63826741568,d=1002 us
[   63.834439] [ 0- 0]t0=63826743904,t1=63827746432,d=1002 us
[   63.835445] [ 0- 0]t0=63827748832,t1=63828752576,d=1003 us
[   63.836164] [ 7- 4]t0=63819412064,t1=63829471328,d=10059 us
[   63.836452] [ 0- 0]t0=63828755936,t1=63829760032,d=1004 us

Now I am wondering if the cyclictest will have the same result using
the relative timer instead of absolute, suppose all the other
conditions are the same?
Also the '-a 0' set affinity to cpu0 and only one timer thread with
'-t 1', don't know why some cyclictest migrate(?) to the other cpus
than cpu0, any comments about this...
Thanks!

On Sun, Mar 23, 2025 at 5:04 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Sat, Mar 22 2025 at 11:20, richard clark wrote:
> > With diff below under the 'cyclictest -a 0 -t 1 -m -p99' trigger from
> > the arm64-based linux box, the interval is 1000us and the arch_timer
> > in the system is: arch_timer: cp15 timer(s) running at 31.25MHz
> > (phys).  1tick = 32ns for the arch timer, I am not sure if those
> > durations less than 1000us are expected?
>
> With your method of measurement yes. There is a german saying, which
> describes this. It roughly translates to:
>
>    "Who measures a lot, might measure a lot of garbage."
>
> But it accurately describes, what you are measuring here. You do:
>
>     t1 = ktime_get();
>     arm_timer(T);
>     schedule();
>     t2 = ktime_get();
>
> and then look at t2 - t1. That only tells you how long the task actually
> slept. But that's ignoring the most important information here:
>
>     arm_timer(T);
>
> cyclictest uses:
>
>            clock_nanosleep(clockid, ABSTIME, &T);
>
> and T is maintained in absolute time on a periodic time line.
>
>     T = starttime + N * interval;
>
> So the only interesting information here is at which time the task
> returns from schedule(), i.e. you want to look at:
>
>         t2 - T
>
> Why? Because that gives you the latency of the wakeup. That's what
> cyclictest is looking at in user space:
>
>            clock_nanosleep(... &T);
>            clock_gettime(..., &T2);
>            latency = T2 - T;
>
> Now what you are looking at is the time at which the cyclictest task
> comes back into the kernel to sleep, which is obviously
>
>            t1 = T[N] + latency[N-1] + execution_time;
>
> But the timer is armed for T[N], so your t2 is:
>
>            t2 = T[N] + latency[N];
>
> You surely can do the remaining math and map that to the output:
>
> > [  165.555795] [ 0- 0]t0=165550399226,t1=165551394303,d=995 us
> > [  165.556802] [ 0- 0]t0=165551398751,t1=165552400997,d=1002 us
>
> Right?
>
> Thanks,
>
>         tglx