Использование памяти модуля ядра

При попытке оценить объем памяти, потребляемый модулем ядра (обычно это драйверы устройств), я попытался использовать утилиту размер, которая задала размер областей статической памяти .ko(. bss,.data,.text и т.д.). Поэтому я ожидал, что сумма этих значений будет в точности равна выходу, заданному командой lsmod сразу после вставки модуля.

Никакое динамическое распределение памяти (kmalloc или vmalloc) не выполняется в функции init(), чтобы гарантировать, что это не вызывает разницу. Поэтому почему существует несоответствие?

Любопытно, что несоответствие было обнаружено как фиксированное количество большую часть времени!

Выходы команды перечислены ниже

размер chardev.ko

text    data     bss     dec     hex   filename
172     448    1024016 1024636  fa27c chardev.ko

lsmod

Module  Size    Used by    Tainted: P
chardev 1025040 0 - Live   0xc009d000

Ответ 1

Вы упомянули, что в функции init не выполняется выделение, но учитываются ли такие вызовы, как register_chrdev (9), которые выделяют внутреннюю память для экземпляра устройства? Комментарий, что это постоянное различие, заставляет меня задаться вопросом, может ли это быть причиной.

Ответ 2

Может быть, функции, используемые модулем, учитываются в размере модуля? Попробуйте

cat /proc/kallsyms | grep module_name

Разница между двумя размерами составляет 404. Текст + данные + 404 = 1024. Может быть, это какая-то проблема детализации? Я не знаю, как размер вычисляется внутри ядра...

Однако код ядра и данные распределяются с использованием динамической памяти. И kmalloc использует предварительно выделенный блок памяти, поэтому вполне вероятно, что есть некоторое округление, когда выделены разделы кода и данных.

Попробуйте увеличить размер разделов данных и посмотреть, изменилось ли изменение размера lsmod

Ответ 3

Без дополнительной информации у меня возникает соблазн предположить, что накладные расходы отладки. Я говорю соблазн, потому что у меня нет конфигурации ядра.