Please do not top post on netdev On Tue, 2017-04-18 at 16:26 -0700, Code Soldier1 wrote: > Eric, > > This alignment flag is passed to the cache constructor and the > allocation is indeed cache aligned. However, since the allocated size > is not a multiple of the alignment, wont memory be wasted ?. We can > get 40 extra bytes without any side effects since they are on the same > cache line ?
We _want_ to align skb to cache lines. Fact that few bytes might be wasted is unfortunate, but negligible. BTW, if you do kmalloc(1025), kmalloc() wastes 1023 bytes. > > kmem_cache_create() code does an ALIGN() to round up the size. > > kasan_cache_create(cachep, &size, &flags); > > size = ALIGN(size, cachep->align); > > This is the size used in calculate_slab_order() to calculate num. I am > assuming that in the non debug case gfp_order will be 0. > > Perhaps I am missing something. > > > On Tue, Apr 18, 2017 at 12:00 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > > On Tue, 2017-04-18 at 10:34 -0700, Code Soldier1 wrote: > >> Hi Folks, > >> > >> I am sure there is a reason for the current sizes of these structures, > >> However the reason is not obvious to me. So please help me understand. > >> > >> Currently the size of sk_buff on an x86_64 system is 232 bytes -- Why > >> is that. I expected it to be a multiple of 32/64 as they are the most > >> common cache lines. Since the alignment calculation will align the > >> structure with the hw cache line, it seems like we might be wasting > >> space ? > >> > >> skb_shared_info on the other hand is perfectly aligned with a size of 320 > >> bytes. > >> > >> Thanks, > >> > > > > The alignment is there. > > Look at skb_init() code, using SLAB_HWCACHE_ALIGN > > > > > > > > > > > > >
