Messages in this thread | | | Subject | Re: [ANNOUNCE] New kernel tree for embedded linux | From | Andi Kleen <> | Date | 07 Apr 2003 21:06:16 +0200 |
| |
Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> The RATIONALE is that on a ppc with some flash, memory, network and > nothing much else, I don't feel like parsing MS-DOS partitions, > offering IPX networking etc., but that junk is still included in > 2.[45].current - unconditionally. And there is more...
Both dos partitions and IPX are already CONFIG_* options. As "conditional" as you can get.
If you want to reduce memory bloat I would start with shrinking the dynamic sized hashtables. That will likely give you several hundred KB depending on the memory size, much more than you could get from code size reductions.
Another obvious candidate for memory reduction would be mem_map (struct page). If you accept some total memory size limit (256MB with 4k pages) you could replace next_hash and pprev_hash with an 16bit index into mem_map and save 8 bytes per 4k of memory. Possible even fold count into flags and save another 4 bytes per 4k of memory For 256MB of memory this would be 768k. That's more than a stripped down kernel has code in total.
Probably more could be saved by attacking other bloated data structures in the kernel.
Really there are many targets that have bigger potential pay off than just code shrinking.
If you want to shrink code:
The TCP/IP stack could be also put on a diet. You likely don't need an backbone router class routing table manager in your embedded system. The code is already modularized enough that it could be replaced with a simple "client" implementation using linked lists for routing tables with minor changes. Unfortunately developing it is still quite some work.
-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/
| |