Hi Arnd,
On Fri, Oct 23, 2020 at 9:52 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
On Sun, Oct 18, 2020 at 2:55 AM Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 15 Oct 2020, Arnd Bergmann wrote:
On Thu, Oct 15, 2020 at 3:19 AM Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> 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.
It would be a fair share of the typical increase of ca. 30 KiB per
kernel release. Still, it would be lost in the noise of the increase for
v5.10-rc1:
add/remove: 1200/455 grow/shrink: 1419/821 up/down: 468970/-93714 (375256)
Function old new delta
_printk_rb_static_infos - 180224 +180224
write_buf 8192 32768 +24576
_printk_rb_static_descs - 24576 +24576
HUF_decompress4X4_usingDTable_internal - 5664 +5664
HUF_decompress4X2_usingDTable_internal - 5006 +5006
__ext4_ioctl - 4774 +4774
sock_ops_convert_ctx_access 3840 8462 +4622
ZSTD_decompressSequences - 3100 +3100
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.
They probably don't have any users.
AFAIK, the only users are the usual triumvirate of amiga/atari/mac
(and perhaps the fleet of VME boards in the Australian navy? ;)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
