From: Greg B. <gb...@po...> - 2000-08-30 07:29:11
|
NIIBE Yutaka wrote: > > To do that, it's good to define the meaning of vmlinux, the Kernel > Image. I'd like to keep this image as the one after "loaded". > Specifically, don't change the LMA of vmlinux for ROM here. It's > better to have another step getting ROM image from vmlinux, and > let the loader to load data section into RAM. > > Why? I'm thinking about the case where we compress the image of data > section on ROM, people may introduce such feature when ROM is small. So the idea is to have the .text and .rodata uncompressed and linked for XIP, but the .data compressed in ROM and copied to RAM? Interesting. I tried a small test: the 59K of .data sections in my current kernel image gzip's down to a measly 8K, which is pretty good compression. But a quick inspection reveals why: about 48K of that 59K are zero bytes. So I suspect there are a lot of variables which could sensibly go into .bss instead of cluttering up .data, even a compressed .data. Once you consider the code needed to uncompress the .data, it may well be that the more useful optimisation would be to move variables to .bss instead of compressing .data. In any case I think it would be useful to investigate. This is perhaps a little off-topic, but Mitch found the following interesting article on reducing the size of the kernel's .data and .bss sections. We haven't actually tried any of these things, but mostly they sound feasible. The author claims to have achieved a .data of 41K and a .bss of 15K (!!). For comparison the figures for the kernel I'm currently running are 59K and 134K respectively. > > > > Subject: > Re: [Handhelds] Linux may be abandoned for WinCE here. > Date: > 19 Jul 2000 08:52:02 +0200 > From: > lars brinkhoff <la...@no...> > To: > ow...@ca... > CC: > han...@ha..., la...@la..., lin...@wa... > Newsgroups: > comp.os.linux.development.system, comp.os.linux.misc, comp.os.linux.advocacy > > > > The following message is a courtesy copy of an article > that has been posted to comp.os.linux.development.system,comp.os.linux.misc,comp.os.linux.advocacy > as well. > > *** I'd be very interested in hearing about work done by others *** > *** to reduce the size of Linux. I already know about Graham *** > *** Stoney's CONFIG_MESSAGES and dead function optimisation *** > *** patches. *** > > Wallace Owen wrote: > > Can anyone tell me what files in the Linux kernel have data > > declarations whose dimensions can be safely reduced? My efforts > > at producing a small kernel have got the code segment down below > > half a meg, but the data segment is 1.5 megabytes. > > I started a port of Linux 2.3.99 to our MIPS R3000-ish device (IDT > RC32064, really). This device usually has 2M flash and 4M RAM. > > To reduce the size of the text and data sections, I sorted the output > of the "size" command and investigated the files with the largest > sections. > > These are the memory-saving changes I arrived at. They are not really > tested, so some of them may break some functionality. > > fs/dcache.c > > Changed HASH_BITS from 14 to 8. This reduces the size of the > cache from 128K to 2K. > > fs/inode.c > > Changed HASH_BITS from 14 to 8. This reduces the size of the > cache from 128K to 2K. > > include/linux/blk.h > > Changed NR_REQUEST from 256 to 16. This reduces the number of > requests that can be queued. The size of the queue is reduce > from 16K to 1K. > > include/linux/major.h > > Changed MAX_BLKDEV and MAX_CHRDEV from 256 to 10 and 20, > respectively. This reduces the number of block and character > devices and saves about 40K. > > kernel/printk.c > > Changed LOG_BUF_LEN from 16384 bytes to 2048 bytes. > > include/linux/tty.h > > Changed NR_PTYS and NR_LDISCS from 256 and 16, respectively, > to 16 and 4, respectively. Saved about 12K. > > Warning: this change may break the pty driver, in which > case further modifications will have to be done to > drivers/char/pty.c. > > kernel/panic.c > > Changed a buffer from 1024 bytes to 200 bytes. > > include/linux/sched.h > > Changed PIDHASH_SZ from 1024 to 16, which saves > 1008 bytes. > > arch/mips/kernel/entry.S > > (Has 21184 bytes of data which might be trimmed?) > > include/linux/mmzone.h > > NR_GPFINDEX from 0x100 to 0x10. Saves 4800 bytes, > but I'm not sure it doesn't break anything. > > net/Makefile, net/socket.c, net/nosocket.c > > Replacing socket.c with nosocket.c, a file containing > dummy replacement functions for those in socket.c, saves > about 24K. > > Warning: this disables the socket API entirely, but it > is currently not used in our product. > > net/Makefile, net/network.a, net/core > > Excluding net/core/core.o from net/network.a doesn't save > anything. I guess core.o isn't referenced by anything > in the rest of the kernel (except maybe socket.c, see > above). > > mm/Makefile, mm/swapfile.c, mm/swap_state.c, mm/noswapfile.c, mm/noswap_state.c > > Replacing swapfile.c with noswapfile.c, and swap_state.c with > noswap_state.c saves about 12K. The no*.c files contains empty > replacement functions. > > Warning: this disables swapping of anonymous memory, which isn't > used in our product. But note that demand paging of executables > still works. > > mm/Makefile, mm/mmap.c > > The functions in mmap.c could probably also be replaced by > empty functions. Estimated saving: 9K (not included in the > grand total below). > > *, CONFIG_MESSAGES > > Applying the CONFIG_MESSAGES patch and disabling all > kernel messages saves about 80K. > > The CONFIG_MESSAGES patch was written by Graham Stoney > <gr...@re...>. > > With all of the above, and only this enabled in .config: > CONFIG_EXPERIMENTAL=y > CONFIG_CPU_R3000=y > CONFIG_CPU_LITTLE_ENDIAN=y > CONFIG_ELF_KERNEL=y > CONFIG_BINFMT_ELF=y > CONFIG_MODULES=y > CONFIG_MODVERSIONS=y > CONFIG_KMOD=y > CONFIG_CROSSCOMPILE=y > , the kernel is down to about 550K. > > Here is the output of "size vmlinux". I think this is without the > CONFIG_MESSAGES patch (it was many months since I worked with this). > > text data bss dec hex filename > 572128 41964 15860 629952 99cc0 vmlinux > > -- > To unsubscribe from this list, send a message to maj...@wa... > with the command "unsubscribe linux-embedded" in the message body. > For more information, see <http://waste.org/mail/linux-embedded>. > Greg. -- These are my opinions not PPIs. |