Now the min_delta is 0x600 (1536) for LoongArch's constant clockevent
device. For a 100MHz hardware timer this means ~15us. This is a little
big, especially for PREEMPT_RT enabled kernels. So reduce it to 1000
(we don't want too small values to affect performance).

Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
---
 arch/loongarch/kernel/time.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/loongarch/kernel/time.c b/arch/loongarch/kernel/time.c
index 46d7d40c87e3..e914b27a7c89 100644
--- a/arch/loongarch/kernel/time.c
+++ b/arch/loongarch/kernel/time.c
@@ -127,7 +127,7 @@ void sync_counter(void)
 int constant_clockevent_init(void)
 {
 	unsigned int cpu = smp_processor_id();
-	unsigned long min_delta = 0x600;
+	unsigned long min_delta = 1000;
 	unsigned long max_delta = (1UL << 48) - 1;
 	struct clock_event_device *cd;
 	static int irq = 0, timer_irq_installed = 0;
-- 
2.43.5

On 2024-11-08 17:15:43 [+0800], Huacai Chen wrote:
> Now the min_delta is 0x600 (1536) for LoongArch's constant clockevent
> device. For a 100MHz hardware timer this means ~15us. This is a little
> big, especially for PREEMPT_RT enabled kernels. So reduce it to 1000
> (we don't want too small values to affect performance).

So this reduces it to 10us. Is anything lower than that bad performance
wise?

> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>

Sebastian

Hi, Sebastian,

On Thu, Nov 14, 2024 at 6:21 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2024-11-08 17:15:43 [+0800], Huacai Chen wrote:
> > Now the min_delta is 0x600 (1536) for LoongArch's constant clockevent
> > device. For a 100MHz hardware timer this means ~15us. This is a little
> > big, especially for PREEMPT_RT enabled kernels. So reduce it to 1000
> > (we don't want too small values to affect performance).
>
> So this reduces it to 10us. Is anything lower than that bad performance
> wise?
Maybe I misunderstood the meaning of min_delta, but if I'm correct,
small min_delta may cause more timers to be triggered, because timers
are aligned by the granularity (min_delta). So I think min_delta
affects performance.

And I choose 10us just because I saw latency improvements when I
reduce 15us to 10us, but no more effect when I reduce it to even
lower.

Huacai



>
> > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
>
> Sebastian

On 2024-11-14 19:46:39 [+0800], Huacai Chen wrote:
> Hi, Sebastian,
Hi,

> On Thu, Nov 14, 2024 at 6:21 PM Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
> >
> > On 2024-11-08 17:15:43 [+0800], Huacai Chen wrote:
> > > Now the min_delta is 0x600 (1536) for LoongArch's constant clockevent
> > > device. For a 100MHz hardware timer this means ~15us. This is a little
> > > big, especially for PREEMPT_RT enabled kernels. So reduce it to 1000
> > > (we don't want too small values to affect performance).
> >
> > So this reduces it to 10us. Is anything lower than that bad performance
> > wise?
> Maybe I misunderstood the meaning of min_delta, but if I'm correct,
> small min_delta may cause more timers to be triggered, because timers
> are aligned by the granularity (min_delta). So I think min_delta
> affects performance.

They are not aligned. Well they get aligned due to the consequences.

In one-shot mode you program the device for the next timer to expire. It
computes the delta between expire-time and now. This delta is then
clamped between min & max delta. See clockevents_program_event().

This means if your timer is supposed to expire in 5us (from now) but
your min delta is set to 15us then the timer device will be programmed
to 15us from now. This is 10us after the expire time of your first
timer. Once the timer devices fires, it will expire all hrtimers which
expired at this point. This includes that timer, that should have fired
10us ago, plus everything else following in the 10us window.

> Huacai

Sebastian

On Thu, Nov 14, 2024 at 9:27 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2024-11-14 19:46:39 [+0800], Huacai Chen wrote:
> > Hi, Sebastian,
> Hi,
>
> > On Thu, Nov 14, 2024 at 6:21 PM Sebastian Andrzej Siewior
> > <bigeasy@linutronix.de> wrote:
> > >
> > > On 2024-11-08 17:15:43 [+0800], Huacai Chen wrote:
> > > > Now the min_delta is 0x600 (1536) for LoongArch's constant clockevent
> > > > device. For a 100MHz hardware timer this means ~15us. This is a little
> > > > big, especially for PREEMPT_RT enabled kernels. So reduce it to 1000
> > > > (we don't want too small values to affect performance).
> > >
> > > So this reduces it to 10us. Is anything lower than that bad performance
> > > wise?
> > Maybe I misunderstood the meaning of min_delta, but if I'm correct,
> > small min_delta may cause more timers to be triggered, because timers
> > are aligned by the granularity (min_delta). So I think min_delta
> > affects performance.
>
> They are not aligned. Well they get aligned due to the consequences.
Then I still think it affects performance (and power
consumption).Because it is different to fire a timer every 1us and
fire 10 timers together at the end of 10us.

Huacai

>
> In one-shot mode you program the device for the next timer to expire. It
> computes the delta between expire-time and now. This delta is then
> clamped between min & max delta. See clockevents_program_event().
>
> This means if your timer is supposed to expire in 5us (from now) but
> your min delta is set to 15us then the timer device will be programmed
> to 15us from now. This is 10us after the expire time of your first
> timer. Once the timer devices fires, it will expire all hrtimers which
> expired at this point. This includes that timer, that should have fired
> 10us ago, plus everything else following in the 10us window.
>
> > Huacai
>
> Sebastian