> The data is where I'd say the bloat would be, and lo and behold is a
> nearly 7-fold increase for the sample you give us _only_ in the .data
> section.
.data is normally not a significant part of programs, because few programs
use global variables that heavily (yes, there are exceptions, like that emacs
thing, but it's not common)
It appear big in ls because it's a very small program, but even there
are absolute numbers don't make much difference (1K vs 7K, even 1K
data needs one 4K page so the actual bloat is only another 4K)
Regarding the stack use: we're using 6.3K kernel stack + separate interrupt
stack in the kernel. While there were a few problems with stack overflow
it was usually very stupid bugs (like someone declaring a big long/pointer
array that just fit on 32bit, but exceeded it on 64bit). The normal
stack frame tend to be not that much bigger.
There is some heap bloat from pointers, but the effects are fairly
limited and I doubt ls will suffer from it significantly. Of course
when you're performance limited on a given problem it may be a good
idea to benchmark both -m32 and -m64, just to see if it's cache bound
by pointers. But I think -m64 is a good default nevertheless, simply
because the generated code is much better.
> BTW, I bet your dynamic relocation tables are a bit larger too.
Somewhat, but does it matter? They are not kept in memory anyways.
-Andi
-
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/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:12 EST