Re: Rusty's module talk at the Kernel Summit

From: Adam J. Richter (adam@yggdrasil.com)
Date: Wed Jul 03 2002 - 10:53:03 EST


On Wed, 03 Jul 2002 22:27:33 +1000, Keith Owens wrote:
>On Wed, 3 Jul 2002 00:31:35 -0700,
>"Adam J. Richter" <adam@yggdrasil.com> wrote:
>> As individual space optimizations go, 4% is respectable,
>>especially for something that has no cost

>It is not at no cost. Getting 4% requires arch dependent code to
>handle all the tables that are affected by partial text removal. I can
>get 2% for nothing by discarding data.init. Discarding text.init is a
>lot harder.
[...]
>The problem is the partial removal of code when there are tables that
>point to _all_ the code. Partial code removal requires a lot of work
>to adjust every table that refers to code and correct them. To make it
>worse, the tables are arch specific. Most architectures have
>__ex_table, with different formats for each arch. Some have unwind
>data, always arch dependent format. MIPS has dbe.

>Data is not referenced by any of these tables so a partial discard of
>data is easy, no side effects to worry about.

        OK, I agree that anyone wanting to implement discarding of
some module init sections would be best off to start with .init.data.

        I don't know enough about the formats of these tables right now
to really understand the best way to handle them, but I suspect that
the simplest approach might be a mechanism where copy_*_user and the like
could generate assembler that does a .pushsection to a different section
depending on the current section, so you could have "__ex_table" and
".init.__ex_table", etc. Then it might be possible to deal with these
sections in a way that is not architecture specific, and be able
to discard the obselete parts of these tables after the init code
has completed. However, this would probably require a gas or gcc
extension.

[...]
>> As I understand it, __ex_table is just for copy_{to,from}_uesr,
>>which would almost never be done from init sections

>__ex_table is used for any code that requires recovery. Mainly
>copy..user but not exclusively.

>>The core kernel already deals with the same issue.

>It does not. There is no code to adjust any tables after discarding
>kernel __init sections. We rely on the fact that the discarded kernel
>area is not reused for executable text.

        Come to think of it, if the core kernel's .text.init pages could
later be vmalloc'ed for module .text section, then I think you may have
found a potential kernel bug.

Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
                         "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:11 EST