I don't mind how people do it, but there are currently two significant
penalties associated with modules on x86. I think other architectures
have analogues.
1) The main kernel is contiguous in physical memory and is mapped with
large (4 MB) pages. This reduces pressure on the TLB. Modules are
loaded in vmalloc memory, which uses small pages, and therefore
competes for TLB space. This is a performance penalty, especially
as most current machines have undersized TLBs already. (A 64-entry
TLB with 4K pages maps 256K at a time. On-chip L2 caches are this
large or larger. Thus, as a crude approximation, every L2 miss also
causes a TLB miss.)
Also, vmalloc space is limited, and contributes to the "why isn't
the kernel seeing all of my 1 GB?" question.
2) Space for module code is allocated in page units. Thus, each module
wastes an average of 2K. If I'm going to have dozens of modules
loaded, small machines are going to notice.
On a related subject, I'd like a kernel image to consist of a series
of concatenated "chunks". The first one is the kernel proper, and then
come various modules and initrd image(s). (There may be an "EOF" chunk,
or just the absence of a magic number.)
All the boot loader has to do is copy the image into contiguous memory
and jump to it. The start of the image (ideally, it'd be PIC) then
relocates itself to wherever it wants and starts assembling the pieces.
Whether this is done by a sort of linker before the kernel boots, or
if the chunks are all ramdisk components and form a userland that the
kernel boots to which assemble the rest of the kernel is not particularly
important. I just want the unnecessary bits to get thrown away once
we've booted. (Kernel bloat should NOT be designed in.)
That would make assembling a custom boot image simple enough for a fancy
boot loader (or fancy tftp server) to do.
-
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 : Tue Jan 15 2002 - 21:00:49 EST