Re: [RFC]: unnecessary padding in various kernel structures

2011-01-05 Thread Ivan Voras

On 04/01/2011 19:59, Roman Divacky wrote:

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.


It looks like padding... to alignment boundary means because of 
struct {...} __aligned(CACHE_LINE_SIZE) and such, and we cannot run 
away from those - maybe you should filter those results out?



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



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[RFC]: unnecessary padding in various kernel structures

2011-01-04 Thread Roman Divacky
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



pgp6ttntmSgRd.pgp
Description: PGP signature