Re: [RFC][PATCH] Reduce number of pointer derefs in various files (kernel/exit.c used as example)

[Ingo Molnar <mingo@elte.hu>]

* Matt Mackall <mpm@selenic.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/