Memory usage of a kernel module
Solution 1
You mention that no allocation is done in the init function, but does that take into account calls such as register_chrdev(9) which allocate memory internally for the device instance? The comment that it is a constant difference makes me wonder if this might be the cause.
Solution 2
May be the functions used by the module are counted into the module size ? Try
cat /proc/kallsyms | grep module_name
The difference between the two size is 404. Text + data + 404 = 1024. May be this is some kind of granularity problem ? I don't know how the size is calculated inside the kernel...
However, kernel code and data are allocated using dynamic memory. And kmalloc uses pre-allocated block of memory, so it is quite likely that there is some rounding up when code and data sections are allocated.
Try to increment the size of the data sections and see if the lsmod reported size change
AIB
A programmer, researcher. Celebrating 10million users :) SOreadytohelp
Updated on June 04, 2022Comments
-
AIB almost 2 years
While trying to estimate the amount of memory consumed by a kernel module (usually device drivers),I tried using the size utility which gave the size of the static memory areas of the .ko ( .bss, .data, .text etc). So I was expecting the sum of these values to be exactly equal to the output given by the lsmod command immediately after inserting the module.
No dynamic memory allocation(kmalloc or vmalloc) is performed in the init() function to ensure that it isn't causing the difference.So why is there a mismatch?
Curiously the mismatch was found to be a fixed amount most of the time!!
The command outputs are listed below
size 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
-
AIB about 15 years@tinkertim Will not the debug overhead be coming in both size and lsmod?
-
Tim Post about 15 years@AIB, I think the size of _init depends on debugging, but only _after the module is inserted. I might be incorrect, I'm actually trying to look it up now :)
-
AIB about 15 yearsIt did not give any size information .Here is the o/p # cat /proc/kallsyms | grep chardev 00000000 a chardev.c [chardev] c009d058 r $LC0 [chardev] c009d400 b p [chardev] c009d000 t cleanup_module [chardev] c009d008 t init_module [chardev]
-
AIB about 15 yearsYea this seems to be the case.