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 ?
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
>
>
>
>
>
--
CS1
