[RFC]: unnecessary padding in various kernel structures
Roman Divacky
rdivacky at freebsd.org
Tue Jan 4 19:18:00 UTC 2011
hi,
clang (svn version) has ability to detect unnecessary padding in structures.
I ran this on kernel build on i386 (stripped GENERIC) and amd64 (full GENERIC),
preprocessed this and posted on web.
The lists contain the file of the definition, name of the structure, size of
the unnecessary padding and reason for the alignment. The last field is
how many times this was hit during the build of the kernel.
The lists are sorted by the size of the padding.
Examples (i386):
dev/usb/controller/ohci.h:64:8: 2 times
padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary
sys/pcpu.h:156:8: 58 times
padding size of 'struct pcpu' with 108 bytes to alignment boundary
sys/pcpu.h:199:2: 58 times
padding struct 'struct pcpu' with 84 bytes to align 'pc_monitorbuf'
dev/usb/controller/ehci.h:170:8: 1 times
padding size of 'struct ehci_qtd' with 58 bytes to alignment boundary
kern/sched_ule.c:206:8: 1 times
padding size of 'struct tdq' with 41 bytes to alignment boundary
Examples(amd64):
net/flowtable.c:179:11: 1 times
padding struct 'struct flowtable' with 124 bytes to align 'ft_udp_idle'
dev/usb/controller/ohci.h:64:8: 2 times
padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary
net/flowtable.c:160:8: 1 times
padding size of 'struct flowtable' with 108 bytes to alignment boundary
vm/uma_int.h:184:8: 6 times
padding size of 'struct uma_cache' with 96 bytes to alignment boundary
vm/uma_int.h:338:19: 5 times
padding struct 'struct uma_zone' with 92 bytes to align 'uz_cpu'
net/flowtable.c:149:8: 1 times
padding size of 'struct flowtable_stats' with 64 bytes to alignment boundary
Full lists can be found here:
http://lev.vlakno.cz/~rdivacky/kernel-unecessary-padding-i386.txt
http://lev.vlakno.cz/~rdivacky/kernel-unecessary-padding-amd64.txt
Instances of some of these structures can be in memory many times. And thus
we can be losing a lot of memory without noticing it. Can you guys look
at the biggest offenders or some other interesting structures in the lists
and do something about it? Maybe be simple reshuffling we can improve things
a lot!
Thank you
Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20110104/28c63077/attachment.pgp
More information about the freebsd-current
mailing list