| Message ID | 20180328155033.GH13942@piout.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hei hei, Am Mittwoch, 28. März 2018, 17:50:33 CEST schrieb Alexandre Belloni: > On 28/03/2018 at 17:31:35 +0200, Alexandre Belloni wrote: > > > Do you have an explanation of why the rate is much higher ? > > > > The core is giving deltas of 31 clocks instead of much more than that, I > > guess I messed up the initialization somewhere. > > I did mess up. > > Alexander, can you test that: Well, I just did. > > diff --git a/drivers/clocksource/timer-atmel-tcb.c > b/drivers/clocksource/timer-atmel-tcb.c index 7fde9cfbf203..bbbacf8c46b0 > 100644 > --- a/drivers/clocksource/timer-atmel-tcb.c > +++ b/drivers/clocksource/timer-atmel-tcb.c > @@ -222,7 +222,7 @@ static int __init tc_clkevt_register(struct device_node > *node, goto err_slow; > clk_disable(tce.clk); > > - clockevents_config_and_register(&tce.clkevt, 32768, 1, bits - 1); > + clockevents_config_and_register(&tce.clkevt, 32768, 1, BIT(bits) - 1); > > ret = request_irq(tce.irq, tc_clkevt2_irq, IRQF_TIMER | IRQF_SHARED, > tce.clkevt.name, &tce); > > This will behave exactly the same as before on 16bits TCB and will have > much less interrupts on 32 bits platforms. This is the result: INT NAME RATE MAX 17 [vel timer@fffa] 1837 Ints/s (max: 1912) 26 [ vel eth0] 3 Ints/s (max: 11) This is not much lower than the ~2150 I reported yesterday? I'm sorry I can just test this on at91sam9g20 currently, I have no understanding of the subsystem, I can't do a decent review. Greets Alex
On 29/03/2018 at 10:01:26 +0200, Alexander Dahl wrote: > Hei hei, > > Am Mittwoch, 28. März 2018, 17:50:33 CEST schrieb Alexandre Belloni: > > On 28/03/2018 at 17:31:35 +0200, Alexandre Belloni wrote: > > > > Do you have an explanation of why the rate is much higher ? > > > > > > The core is giving deltas of 31 clocks instead of much more than that, I > > > guess I messed up the initialization somewhere. > > > > I did mess up. > > > > Alexander, can you test that: > > Well, I just did. > > > > > diff --git a/drivers/clocksource/timer-atmel-tcb.c > > b/drivers/clocksource/timer-atmel-tcb.c index 7fde9cfbf203..bbbacf8c46b0 > > 100644 > > --- a/drivers/clocksource/timer-atmel-tcb.c > > +++ b/drivers/clocksource/timer-atmel-tcb.c > > @@ -222,7 +222,7 @@ static int __init tc_clkevt_register(struct device_node > > *node, goto err_slow; > > clk_disable(tce.clk); > > > > - clockevents_config_and_register(&tce.clkevt, 32768, 1, bits - 1); > > + clockevents_config_and_register(&tce.clkevt, 32768, 1, BIT(bits) - 1); > > > > ret = request_irq(tce.irq, tc_clkevt2_irq, IRQF_TIMER | IRQF_SHARED, > > tce.clkevt.name, &tce); > > > > This will behave exactly the same as before on 16bits TCB and will have > > much less interrupts on 32 bits platforms. > > This is the result: > > INT NAME RATE MAX > 17 [vel timer@fffa] 1837 Ints/s (max: 1912) > 26 [ vel eth0] 3 Ints/s (max: 11) > > This is not much lower than the ~2150 I reported yesterday? > > I'm sorry I can just test this on at91sam9g20 currently, I have no > understanding of the subsystem, I can't do a decent review. Hum, are you sure, I went from: INT NAME RATE MAX 16 [evel timer@fc0] 1027 Ints/s (max: 1028) 21 [ evel at_xdmac] 3 Ints/s (max: 3) 30 [ evel ttyS0] 2 Ints/s (max: 2) to: INT NAME RATE MAX 16 [evel timer@fc0] 6 Ints/s (max: 9) 21 [ evel at_xdmac] 2 Ints/s (max: 2) 30 [ evel ttyS0] 2 Ints/s (max: 2)
Hei hei, Am Donnerstag, 29. März 2018, 10:01:26 CEST schrieb Alexander Dahl: > This is the result: > > INT NAME RATE MAX > 17 [vel timer@fffa] 1837 Ints/s (max: 1912) > 26 [ vel eth0] 3 Ints/s (max: 11) Above was with v4.16-rc7+, and CONFIG_ATMEL_CLOCKSOURCE_TCB=y, CONFIG_ATMEL_TCLIB=n (as one might see in the name column). Now, v4.16-rc7+, with CONFIG_ATMEL_CLOCKSOURCE_PIT=y, CONFIG_ATMEL_TCLIB=y, CONFIG_ATMEL_TCB_CLKSRC=y (old driver I guess): INT NAME RATE MAX 19 [ vel tc_clkevt] 1898 Ints/s (max: 1945) 26 [ vel eth0] 3 Ints/s (max: 11) So the rates here are roughly the same with old and new driver and the same kernel source. As Alexandre stated in IRC, the rates should be the same with old and new driver on the otherwise same kernel source. I just double checked it, and with the other clocksource on v4.16-rc7+ I get: INT NAME RATE MAX 17 [vel timer@fffa] 1904 Ints/s (max: 1922) 26 [ vel eth0] 6 Ints/s (max: 7) The lower rates I reported yesterday were from older kernels v4.14.29-rt25 and v4.15.13, so there might be the question why v4.16-rc7+ has a much higher rate with tc_clkevt? But there's no real difference between tc_clkevt and timer@fffa… when both measured with v4.16-rc7+ on this target. I know Alexandre has lower rates though, may depend on other parameters. So for completeness, I just tested the clean v4.16-rc7 without this patch series: INT NAME RATE MAX 19 [ vel tc_clkevt] 1903 Ints/s (max: 1930) 26 [ vel eth0] 7 Ints/s (max: 7) Basically the same for this one, too. HTH & Greets Alex
diff --git a/drivers/clocksource/timer-atmel-tcb.c b/drivers/clocksource/timer-atmel-tcb.c index 7fde9cfbf203..bbbacf8c46b0 100644 --- a/drivers/clocksource/timer-atmel-tcb.c +++ b/drivers/clocksource/timer-atmel-tcb.c @@ -222,7 +222,7 @@ static int __init tc_clkevt_register(struct device_node *node, goto err_slow; clk_disable(tce.clk); - clockevents_config_and_register(&tce.clkevt, 32768, 1, bits - 1); + clockevents_config_and_register(&tce.clkevt, 32768, 1, BIT(bits) - 1); ret = request_irq(tce.irq, tc_clkevt2_irq, IRQF_TIMER | IRQF_SHARED, tce.clkevt.name, &tce);