Re: [patch 00/43] ktimer reworked

[Ingo Molnar]

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