При попытке оценить объем памяти, потребляемый модулем ядра (обычно это драйверы устройств), я попытался использовать утилиту размер, которая задала размер областей статической памяти .ko(. bss,.data,.text и т.д.). Поэтому я ожидал, что сумма этих значений будет в точности равна выходу, заданному командой lsmod сразу после вставки модуля.
Никакое динамическое распределение памяти (kmalloc или vmalloc) не выполняется в функции init(), чтобы гарантировать, что это не вызывает разницу. Поэтому почему существует несоответствие?
Любопытно, что несоответствие было обнаружено как фиксированное количество большую часть времени!
Выходы команды перечислены ниже
text data bss dec hex filename
172 448 1024016 1024636 fa27c chardev.ko
Module Size Used by Tainted: P
chardev 1025040 0 - Live 0xc009d000
Вы упомянули, что в функции init не выполняется выделение, но учитываются ли такие вызовы, как register_chrdev (9), которые выделяют внутреннюю память для экземпляра устройства? Комментарий, что это постоянное различие, заставляет меня задаться вопросом, может ли это быть причиной.
Может быть, функции, используемые модулем, учитываются в размере модуля? Попробуйте
cat /proc/kallsyms | grep module_name
Разница между двумя размерами составляет 404. Текст + данные + 404 = 1024. Может быть, это какая-то проблема детализации? Я не знаю, как размер вычисляется внутри ядра...
Однако код ядра и данные распределяются с использованием динамической памяти. И kmalloc использует предварительно выделенный блок памяти, поэтому вполне вероятно, что есть некоторое округление, когда выделены разделы кода и данных.
Попробуйте увеличить размер разделов данных и посмотреть, изменилось ли изменение размера lsmod
Без дополнительной информации у меня возникает соблазн предположить, что накладные расходы отладки. Я говорю соблазн, потому что у меня нет конфигурации ядра.