* Matt Mackall <[email protected]> wrote:
> > > Ohh, and before I forget, besides the fact that this should speed
> > > things up a little bit it also has the added benefit of reducing the
> > > size of the generated code. The original kernel/exit.o file was 19604
> > > bytes in size, the patched one is 19508 bytes in size.
> >
> > nice. Just to underline your point, on x86, with gcc 4.0.2, i'm getting
> > this with your patch:
> >
> > text data bss dec hex filename
> > 11077 0 0 11077 2b45 exit.o.orig
> > 10997 0 0 10997 2af5 exit.o
> >
> > so 80 bytes shaved off. I think such patches also increase readability.
>
> Readability improved: good.
> 37 lines of patch for 80-100 bytes saved: not so good.
i'd take a 37 lines readability patch even if it didnt give us a byte of
text back. The fact that it also reduces text size on the latest gcc in
rawhide is an added bonus. (of course the patch is 2.6.16 material)
in fact we frequently apply patches that _reduce_ readability but which
e.g. reduce the number of 'current->' dereferences. (That too is
something the compiler could figure out.)
also, besides the size reduction effect, this patch is also a
speed-micro-optimization.
> So while this is a good style direction, I don't think it's worth the
> churn. And unlike kzalloc and the like, this particular optimization
> is perfectly doable by a compiler. So I'd rather wait for the compiler
> to get smarter than change code for such modest improvements.
>
> FYI, much other low-hanging size-reduction fruit remains in the
> kernel. Lots of it in the form of duplicate code.
i agree with you that other low-hanging fruits exist, but this does not
diminish the value of this patch. The patch is obviously correct, it is
cleaner and improves size and speed. Size reduction alone does not
necessarily trump cleanliness, but in this particular case all factors
show towards acceptance.
furthermore, i think that even if it's a small step, we should encourage
every effort that reduces the kernel's text size. The 2.4 -> 2.6
transition blew up the kernel by ~50%, and we've got to win back some of
that. (Kernel size is one of the main disadvantages of Linux in the
embedded market, compared to other OSs.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
