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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:10 UTC