[Ksummit-2012-discuss] Topic proposal: Finding and eliminating kernel work creation schemes

James Bottomley James.Bottomley at HansenPartnership.com
Tue Jun 19 07:39:52 UTC 2012

On Mon, 2012-06-18 at 18:07 -0700, Tim Bird wrote:
> On 06/16/2012 08:53 AM, David Woodhouse wrote:
> > On Sat, 2012-06-16 at 07:54 -0700, Greg KH wrote:
> >> Even the CONFIG_TINY people usually want to plug their device into
> >> something at some point in time, and if not, it really isn't saving
> >> them much, if any, memory to not do so. 
> FWIW, Sony has embedded devices that ship both with and without
> CONFIG_HOTPLUG turned on.  It may be interesting to some that
> we turn CONFIG_HOTPLUG on for memory-constrained devices, and
> use it to move memory into and out of the Linux portion of the
> system, at times when we know it will be useful for Linux
> and not needed elsewhere.
> More concretely, we have a camera with 32M of RAM, where 16M is
> normally allocated to Linux, and 16M to the image sensor.
> During bootup, 8M or 16M of that second pool are made
> available to Linux to  improve boot time, and then removed
> from Linux for use by the camera after boot.

So this would be an interesting case to try with and without
CONFIG_HOTPLUG.  I'm not proposing to remove __init and __exit, and I
suspect you're getting most of your free memory after boot from __init,
but it would be useful to validate.

> > And even if it was, I think the onus would be on anyone who wants to
> > preserve those saving, to come up with an automated way of dropping the
> > unneeded bits from the final binary *without* cluttering the source
> > code.
> Recently, I've been doing some research on exactly this.   That is,
> using automation and annotations outside the source code to remove
> unneeded bits.  I don't know if I'll have any results to show by
> August  (if not, the project will likely have been canceled),
> but if people are interested I can discuss what I'm doing
> in a hallway track.

So this too, would be useful.  The direction I'm trying to push us in is
automated, so things like --gc-sections (when it works).  It would be
useful to compare the two approaches and see if there is any additional
benefit from the annotation approach ... and whether it's worth the
hassle of trying to preserve the annotations.

> > The -ffunction-sections --gc-sections approach works relatively well,
> > and could feasibly be extended to identify those functions which are
> > referenced, even indirectly, from non-init code. Our tools already do
> > half the fun work of that anyway, just for validation purposes.
> What tools are you referring to here?

He means the section mismatch checking tools.  The idea is that once you
compile every function in its own section, you can discard any section
that is either unreferenced by the core or which doesn't export a symbol
(because they're provably not used in the final image).


More information about the Ksummit-2012-discuss mailing list