[Ksummit-2012-discuss] [ATTEND] "Modularize" built-in componets to expunge them if they are unnecessary; Wither the baseline attendance.

H. Peter Anvin hpa at zytor.com
Mon Jun 18 03:48:44 UTC 2012

On 06/17/2012 12:28 PM, Konrad Rzeszutek Wilk wrote:
> Hello All,
> Would like to discuss a mechanism to "modularize" built-in components. Meaning that
> drivers/subsystems that are built in with CONFIG_XX=y if they fail to start
> (say AMD IOMMU on Intel hardware) anything but zero are expunged from the .text section.
> Specifically I want to discuss various methods this can be achieved for this:
> 1) make various early stage drivers behave as modules and load them the same way-ish
> (hand-waving) as modules. 2) compaction and re-linking of various text-section around
> the codes that did not get loaded 3) other ways?

Funny enough, I actually discussed this exact thing with Linus over 10
years ago; it might be close to 15 years ago now.

The idea was basically "pre-linked dynamic modules", however, Linus
wanted them allocated out of the direct map rather than vmalloc space
like runtime modules -- this is doable since it is a static allocation
and we just punch holes.

So far so good.  This is where it gets ugly:

1. Internal fragmentation.  If each module pads .text/.rodata/.data to
page boundaries, there can be quite a bit of memory lost.

2. Messes with R/RW/RX separation.  The holes being created by freeing
modules means large pages get broken up, adding to TLB pressure.

The good part of this method is that being pre-linked, these modules do
not add significantly to the boot time.  Of course, this assumes someone
actually feels motivated to implement them, which hasn't happened yet.

There are other methods, of course, and some might have different
tradeoffs; in particular something that explicitly creates a compact set
of in-use modules might have lower runtime overhead, but probably a
higher boot time penalty.


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

More information about the Ksummit-2012-discuss mailing list