* CLOCK_AUX stepping
@ 2025-08-25 9:26 Miroslav Lichvar
2025-08-25 10:22 ` Thomas Weißschuh
0 siblings, 1 reply; 3+ messages in thread
From: Miroslav Lichvar @ 2025-08-25 9:26 UTC (permalink / raw)
To: Thomas Gleixner, Thomas Weißschuh; +Cc: linux-kernel, john.stultz
There is an issue with the new system auxiliary clocks. When I make
a larger step of a CLOCK_AUX clock (by clock_settime() or
adjtimex(ADJ_SETOFFSET)), the system slows down significantly to
almost being unusable. This didn't happen with the original
tglx/timers/ptp/driver-auxclock branch, but happens with 6.17-rc1
and later.
Reproducer:
- echo 1 > /sys/kernel/time/aux_clocks/0/aux_clock_enable
- git clone -b staging https://github.com/mlichvar/linuxptp.git
- cd linuxptp && make
- ./phc_ctl CLOCK_AUX0 set
"echo 0 > .../aux_clock_enable" revives the system.
I'm not sure if this isn't just a symptom, but the top functions
reported by perf are:
87.10% swapper [kernel.kallsyms] [k] queued_spin_lock_slowpath
6.84% rcu_exp_gp_kthr [kernel.kallsyms] [k] queued_spin_lock_slowpath
1.90% rcu_exp_gp_kthr [kernel.kallsyms] [k] smp_call_function_single
--
Miroslav Lichvar
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CLOCK_AUX stepping
2025-08-25 9:26 CLOCK_AUX stepping Miroslav Lichvar
@ 2025-08-25 10:22 ` Thomas Weißschuh
2025-08-25 10:45 ` Miroslav Lichvar
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Weißschuh @ 2025-08-25 10:22 UTC (permalink / raw)
To: Miroslav Lichvar; +Cc: Thomas Gleixner, linux-kernel, john.stultz
Hi Miroslav,
thanks for the report.
On Mon, Aug 25, 2025 at 11:26:12AM +0200, Miroslav Lichvar wrote:
> There is an issue with the new system auxiliary clocks. When I make
> a larger step of a CLOCK_AUX clock (by clock_settime() or
> adjtimex(ADJ_SETOFFSET)), the system slows down significantly to
> almost being unusable. This didn't happen with the original
> tglx/timers/ptp/driver-auxclock branch, but happens with 6.17-rc1
> and later.
>
> Reproducer:
> - echo 1 > /sys/kernel/time/aux_clocks/0/aux_clock_enable
> - git clone -b staging https://github.com/mlichvar/linuxptp.git
> - cd linuxptp && make
> - ./phc_ctl CLOCK_AUX0 set
>
> "echo 0 > .../aux_clock_enable" revives the system.
For high offsets we are stuck looping in __iter_div_u64().
As far as I know, doing regular divisions in the timekeeping hot patch are
problematic on some architectures, so instead of storing the offset as a
single ktime_t, we might need to switch to 'struct timespec64' and do the
division on clock adjustments.
Can you try the following patch for now?
diff --git a/kernel/time/vsyscall.c b/kernel/time/vsyscall.c
index 8ba8b0d8a387..8190e9dc6569 100644
--- a/kernel/time/vsyscall.c
+++ b/kernel/time/vsyscall.c
@@ -8,6 +8,7 @@
*/
#include <linux/hrtimer.h>
+#include <linux/math64.h>
#include <linux/timekeeper_internal.h>
#include <vdso/datapage.h>
#include <vdso/helpers.h>
@@ -143,6 +144,7 @@ void vdso_time_update_aux(struct timekeeper *tk)
struct vdso_timestamp *vdso_ts;
struct vdso_clock *vc;
s32 clock_mode;
+ u32 nsec32;
u64 nsec;
vc = &vdata->aux_clock_data[tk->id - TIMEKEEPER_AUX_FIRST];
@@ -163,7 +165,8 @@ void vdso_time_update_aux(struct timekeeper *tk)
nsec = tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift;
nsec += tk->offs_aux;
- vdso_ts->sec += __iter_div_u64_rem(nsec, NSEC_PER_SEC, &nsec);
+ vdso_ts->sec += div_u64_rem(nsec, NSEC_PER_SEC, &nsec32);
+ nsec = nsec32;
nsec = nsec << tk->tkr_mono.shift;
vdso_ts->nsec = nsec;
}
Thomas
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: CLOCK_AUX stepping
2025-08-25 10:22 ` Thomas Weißschuh
@ 2025-08-25 10:45 ` Miroslav Lichvar
0 siblings, 0 replies; 3+ messages in thread
From: Miroslav Lichvar @ 2025-08-25 10:45 UTC (permalink / raw)
To: Thomas Weißschuh; +Cc: Thomas Gleixner, linux-kernel, jstultz
On Mon, Aug 25, 2025 at 12:22:34PM +0200, Thomas Weißschuh wrote:
> For high offsets we are stuck looping in __iter_div_u64().
> As far as I know, doing regular divisions in the timekeeping hot patch are
> problematic on some architectures, so instead of storing the offset as a
> single ktime_t, we might need to switch to 'struct timespec64' and do the
> division on clock adjustments.
>
> Can you try the following patch for now?
The patch fixes the problem for me. Thanks.
> diff --git a/kernel/time/vsyscall.c b/kernel/time/vsyscall.c
> index 8ba8b0d8a387..8190e9dc6569 100644
> --- a/kernel/time/vsyscall.c
> +++ b/kernel/time/vsyscall.c
> @@ -8,6 +8,7 @@
> */
>
> #include <linux/hrtimer.h>
> +#include <linux/math64.h>
> #include <linux/timekeeper_internal.h>
> #include <vdso/datapage.h>
> #include <vdso/helpers.h>
> @@ -143,6 +144,7 @@ void vdso_time_update_aux(struct timekeeper *tk)
> struct vdso_timestamp *vdso_ts;
> struct vdso_clock *vc;
> s32 clock_mode;
> + u32 nsec32;
> u64 nsec;
>
> vc = &vdata->aux_clock_data[tk->id - TIMEKEEPER_AUX_FIRST];
> @@ -163,7 +165,8 @@ void vdso_time_update_aux(struct timekeeper *tk)
>
> nsec = tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift;
> nsec += tk->offs_aux;
> - vdso_ts->sec += __iter_div_u64_rem(nsec, NSEC_PER_SEC, &nsec);
> + vdso_ts->sec += div_u64_rem(nsec, NSEC_PER_SEC, &nsec32);
> + nsec = nsec32;
> nsec = nsec << tk->tkr_mono.shift;
> vdso_ts->nsec = nsec;
> }
>
>
>
> Thomas
>
--
Miroslav Lichvar
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-08-25 10:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-25 9:26 CLOCK_AUX stepping Miroslav Lichvar
2025-08-25 10:22 ` Thomas Weißschuh
2025-08-25 10:45 ` Miroslav Lichvar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).