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

[Arnd Bergmann]

On Sun, Oct 18, 2020 at 2:55 AM Finn Thain <fthain at telegraphics.com.au> wrote:
> On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain <fthain at telegraphics.com.au> wrote:
> > > 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.

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

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

> > 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