[RFC]: unnecessary padding in various kernel structures

From: Roman Divacky <rdivacky_at_freebsd.org>
Date: Tue, 4 Jan 2011 19:59:30 +0100
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


Received on Tue Jan 04 2011 - 18:18:00 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:10 UTC