Kernel modul vs. hard-linked kód

 ( trey | 2001. december 10., hétfő - 22:03 )

Felmerült egy kérdés:



Mi a sebességbeli különbség a betölthető kernelmodul (loadable kernelmodule) és a fixen a kernelbe fordított kód (hard-linked code) között. Azt ugye tudjuk, hogy a ritkán használt dolgokat célszerű modulba fordítni, mert ha éppen nem használjuk, nem foglal memóriát, viszont ha szükség van rá, akkor elegendő betölteni és máris használhatjuk (vagy akár automatizálhatjuk ezt a folyamatot, és dinamikusan töltõdik be).

A legfontosabb kérdés az, hogy mit érdemes modulba fordítani, mit nem és az, hogy vajon a modulba fordított eszközmeghajtó nem lassabb-e a fixen kernelbe fordított kódnál.

Ha feltesszük a kérdést, hogy lassabb-e a modul, általában rávágjuk, hogy lassabb. Biztos ez?A mérések szerint lassabb. A különbség a hard-linked kód javára nagyobb lehet mint 5%. A magyarázat itt következik, nem fordítom le, nem akarom rosszul lefordítani:

"The biggest, perhaps, relates to how loadable modules are placed in kernel memory. The code for a module needs to live in a contiguous address space. The kernel sets up that address space with a function called vmalloc, which allocates memory with virtual addresses. In other words, a loadable module is in an address space that is visible to the kernel, but which is separate from where the core kernel code goes.

This difference is important. The core kernel address space is a direct map of physical memory; it can be handled very efficiently in the processor's page table. Indeed, on some processors, a single page table entry covers the entire kernel. Space obtained from vmalloc, instead, uses one page table entry per memory page. A greater number of page table entries means more lookups, and more translation buffer misses.

One estimate is that the slowdown can be as much as 5%. Given this problem, why not load modules into the regular kernel memory space? Module code requires a contiguous address space. Since the standard kernel space is a direct map of physical memory, contiguous address spaces must also be contiguous in physical memory. Once the system has been running for a while, finding even two physically contiguous pages can be a challenge; finding enough to load a large module can be almost impossible."

Nakérem, tehát Andrea Arcangeli írt egy kernelpatch-et, amely megpróbál folyamatos memóriarészt keresni a modul számára, ha ez sikertelen maradna, akkor a régi jól bevált vmalloc-al oldja meg a problémát.

Szóval érdemes elgondolkodni, hogy mit fordítunk modulba, és mit fixen a kernelbe. Lehet, hogy csak 5% az eltérés, de lehet, hogy több. Akkor most érdemes modulba? Vagy nem? Vagy de? Vagy ... Vagy én olvasom rosszul a dolgot? ;-)