Re: [RFC 13/13] m68k: mac: convert to generic clockevent

On Sun, Oct 18, 2020 at 2:55 AM Finn Thain [off-list ref] wrote:

On Thu, 15 Oct 2020, Arnd Bergmann wrote:

quoted

On Thu, Oct 15, 2020 at 3:19 AM Finn Thain [off-list ref] wrote:

quoted

On Sat, 10 Oct 2020, Arnd Bergmann wrote:

That configuration still produces the same 5 KiB of bloat. I see that
kernel/time/Kconfig has this --

# Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is
# only related to the tick functionality. Oneshot clockevent devices
# are supported independent of this.
config TICK_ONESHOT
        bool

But my question was really about both kinds of dead code (oneshot device
support and oneshot tick support). Anyway, after playing with the code for
a bit I don't see any easy way to reduce the growth in text size.

Did you look more deeply into where those 5KB are? Is this just
the code in kernel/time/{clockevents,tick-common}.c and the
added platform specific bits, or is there something more?
I suppose the sysfs interface and the clockevents_update_freq()
logic are not really needed on m68k, but it wouldn't make much
sense to split those out either.

How does the 5KB bloat compare to the average bloat we get
from one release to the next? Geert has been collecting statistics
for this.

quoted

Yes, makes sense. I think the one remaining problem with the periodic
mode in this driver is that it can drop timer ticks when interrupts are
disabled for too long, while in oneshot mode there may be a way to know
how much time has passed since the last tick as long as the counter does
not overflow.

Is there any benefit from adopting a oneshot tick (rather than periodic)
if no clocksource is consulted when calculating the next interval? (I'm
assuming NO_HZ is not in use, for reasons discussed below.)

If the clocksource does not set CLOCK_SOURCE_IS_CONTINOUS,
the kernel will keep using periodic timers and not allow hrtimers.

quoted

I would agree that despite this oneshot mode is probably worse overall
for timekeeping if the register accesses introduce systematic errors.

It probably has to be tried. But consulting a VIA clocksource on every
tick would be expensive on this platform, so if that was the only way to
avoid cumulative errors, I'd probably just stick with the periodic tick.

I'm sure there is a tradeoff somewhere. Without hrtimers, some
events will take longer when they have to wait for the next tick, and
using NO_HZ_FULL can help help make things faster on some
workloads.

quoted

The arm/rpc timer seems to be roughly in the same category as most of
the m68k ones or the i8253 counter on a PC. It's possible that some of
them could use the same logic as drivers/clocksource/i8253.o as long as
there is any hardware oneshot mode.

There appear to be 15 platforms in that category. 4 have no clocksource
besides the jiffies clocksource, meaning there's no practical alternative
to using a periodic tick, like you did in your RFC patch:

arch/m68k/apollo/config.c
arch/m68k/q40/q40ints.c
arch/m68k/sun3/sun3ints.c
arch/m68k/sun3x/time.c

Do any of these have users? I'm fairly sure sun3x has never worked in mainline,
sun3 seems to still need the same few patches it did 20 years ago. I
couldn't find
much about Linux on Apollo or q40, the information on the web for either
of them seems to all be for linux-2.4 kernels.

The other 11 platforms in that category also have 'synthetic' clocksources
derived from a timer reload interrupt. In 3 cases, the clocksource read
method does not (or can not) check for a pending counter reload interrupt.
For these also, I see no practical alternative to the approach you've
taken in your RFC patch:

arch/m68k/68000/timers.c
arch/m68k/atari/time.c
arch/m68k/coldfire/timers.c

Agreed. It's possible there is a way, but I don't see one either.

That leaves 8 platforms that have reliable clocksource devices which
should be able to provide an accurate reading even in the presence of a
dropped tick (due to drivers disabling interrupts for too long):

arch/arm/mach-rpc/time.c
arch/m68k/amiga/config.c
arch/m68k/bvme6000/config.c
arch/m68k/coldfire/sltimers.c
arch/m68k/hp300/time.c
arch/m68k/mac/via.c
arch/m68k/mvme147/config.c
arch/m68k/mvme16x/config.c

But is there any reason to adopt a oneshot tick on any of these platforms,
if NO_HZ won't eliminate the timer interrupt that's needed to run a
'synthetic' clocksource?

I would expect that these could be changed to behave more like
drivers/clocksource/i8253.c, which does support a clocksource
in oneshot mode.

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel