Re: [patch 00/43] ktimer reworked

From: Ingo Molnar
Date: Wed Nov 30 2005 - 21:19:37 EST



* Andrew Morton <akpm@xxxxxxxx> wrote:

> Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> >
> > this patch series is a refactored version of the ktimer-subsystem patch.
>
> 25 files changed, 3364 insertions(+), 1827 deletions(-)
>
> allnoconfig, before:
>
> text data bss dec hex filename
> 764888 157221 53748 975857 ee3f1 vmlinux
>
> after:
>
> text data bss dec hex filename
> 766712 157741 53748 978201 eed19 vmlinux
>
> Remind me what we gained for this?

well, for 1824 bytes of code [*] and 520 bytes of data you got a new,
clean timer subsystem, which is per-clock tree based and hres-timers
ready. It also doesnt scan all active timers linearly and fixes them up
whenever NTP decides to mend the clock a bit. It also has no jiffy
dependencies and has nsec resolution with timeouts of up to 292 years,
to the nanosec. It has no subjiffies, no HZ, no tradeoffs.

note that ktimer.o itself is larger than 1824 bytes:

size kernel/ktimer.o
text data bss dec hex filename
3912 100 0 4012 fac kernel/ktimer.o

so it has already offset roughly half of its size.

we can (and will) try to improve it further, but if anyone desires to
get it for free, that's probably not possible. (only 'probable' because
we have not converted posix-cpu-timers yet, another ktimer conversion
candidate with code reduction potential)

it had to be a new set of APIs, which all take text space. We'll try to
shave off some more .text, but miracles are not expected.

Ingo

[*] if you enable CONFIG_KTIME_SCALAR, then on x86 we get denser
ktime_t code. We keep it off by default to give the union
representation testing (the scalar representation is the more
trivial case). It should shave off another 300 bytes from your
kernel's size. We'll probably enable KTIME_SCALAR on x86 later on.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/