linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).