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