* Aaro Koskinen <aaro.koskinen@xxxxxxxxx> [101223 04:31]: > Hi, > > On Wed, 22 Dec 2010, Tony Lindgren wrote: > >* Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> [101221 14:00]: > >>On Tue, 21 Dec 2010 11:27:35 -0800 > >>Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >>>>Therefore, we introduce an infrastructure that allows to put code > >>>>and data into specific sections, called "conditional sections". All > >>>>those sections are compiled into the final kernel image, but at > >>>>runtime, by calling a function, we can get rid of the unused > >>>>sections. > >>> > >>>Great, something is certainly needed to free the unused memory. > >> > >>Nice to see that the idea is welcome. Did you had a look at the > >>implementation in patch 1/6 ? > > > >No not yet, will take a look after we're done with this upcoming > >merge window.. > > I also think the idea is good, and this should be maybe posted to wider > audience than just linux-omap. > > >>However, in order to be able to free each section independently from > >>another, I have to page align all those conditional sections. This > >>means that having one section for only a tiny amount of data is going > >>to waste space instead of saving space. So the conditional section > >>should gather a sufficiently large amount of data (> 4 KB) to actually > >>be valuable. > > > >Yeah I don't know how much non-init data we have for each board-*.c > >file. Maybe there is not much for each machine. > > I took a quick look at omap2plus_defconfig kernel, and non-init text/data > for 29 boards takes 85K. If we would page align those memory consumption > would increase during init to 29*8=232K, but after other boards are > freed we would eventually save 85-8=77K. That does not sounds like a huge savings as some bootloaders like nolo have a 2MB kernel size limitation.. > Under mach-omap2, another big consumer is clock data which takes also > around 80 K, while e.g. on 2420 only 14 K is needed. This eventually should be all __initdata and only the clock data for the booted omap should be allocated during the boot. Sounds like the best way to reduce the size of the image immediately is to make everything possible a module for the defconfigs, then use the standard minimal kernel + initramfs booting. That will make it easy for all the distros to use it too. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
