In function __alloc_skb, original parameter size=4155,Do we know what kind of size is being passed to __alloc_skb() in thisIf it's the former, with big enough size passed to __alloc_skb(), the
networking code might be taking a hit from the SLUB page allocator
pass-through.
case?
SKB_DATA_ALIGN(size)=4224, sizeof(struct skb_shared_info)=472, so
__kmalloc_track_caller's parameter size=4696.
Maybe we want to do something like this.This patch amost fixes the netperf UDP-U-4k issue.
SLUB: revert page allocator pass-through
#slabinfo -AD
Name Objects Alloc Free %Fast
:0000256 1658 70350463 70348946 99 99 kmalloc-8192 31 70322309 70322293 99 99 :0000168 2592 143154 140684 93 28 :0004096 1456 91072 89644 99 96 :0000192 3402 63838 60491 89 11 :0000064 6177 49635 43743 98 77
So ïkmalloc-8192 appears. Without the patch, ïkmalloc-8192 hides.
ïkmalloc-8192's default order on my 8-core stoakley is 2.
1) If I start CPU_NUM clients and servers, SLUB's result is about 2% better than SLQB's;
2) If I start 1 clinet and 1 server, and bind them to different physical cpu, SLQB's result
is about 10% better than SLUB's.
I don't know why there is still 10% difference with item 2). Maybe cachemiss causes it?