Hello, Here is a patchset that proposes a mechanism to get rid at runtime of unused data and code sections, depending on the SoC we are currently running on.
WARNING: This is only a proof-of-concept, there are many known issues. The sole purpose of this patch is to get some feedback on whether the idea is useful or not, and whether it's worth cleaning up the remaining issues. It is for the moment presented on the linux-omap@ list only, as the usage is only demonstrated on OMAP, but the core infrastructure is mostly architecture-independent (except a modification in the architecture-specific linker script). A trend in the kernel support for SoC is to build a single kernel that works accross a wide range of SoC inside a SoC family, or even in the future SoC of different families. While this is very interesting to reduce the number of kernel images needed to support a large number of hardware platforms, it allows means that the kernel image size is increasing. Portions of code and data are specific to a given SoC (clock structures, hwmod structures on OMAP, etc.) and only the portion relevant for the current SoC the kernel is running on is actually useful. The rest of the code and data remains in memory forever. While __init and __initdata can solve some of those cases, it is not necessarly easy to use, since the code/data that is actually useful needs to be copied so that it is kept after the init memory cleanup. 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. The first patch introduces the generic infrastructure. See the description of this patch for details on how it is implemented. The second patch introduces macros to mark code/data to be OMAP2/3/4-specific. The third, fourth and fith patches mark some clock and hwmod data as being OMAP2, OMAP3 or OMAP4 specific. Unfortunately, I haven't found a way of marking the strings inside the structures to be part of a particular section, so the memory used for those strings is not reclaimed. The sixth patch modifies the BeagleBoard board code to call the function that frees the OMAP2 and OMAP4 specific code and data. At boot, what I have is: Freeing unused conditional section: omap2 data 0xc09a9000 -> 0c09b2000 (sz=36864) Freeing unused conditional section: omap4 data 0xc09ba000 -> 0c09c2000 (sz=32768) Which means that 68 KB of memory has been freed. Obviously, I haven't marked all code/data, so higher gains can be expected. Regards, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
