From: Jesper Dangaard Brouer <brouer@redhat.com> To: netdev@vger.kernel.org Cc: Alexander Duyck <alexander.duyck@gmail.com>, linux-mm@kvack.org, Jesper Dangaard Brouer <brouer@redhat.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Christoph Lameter <cl@linux.com> Subject: [PATCH 0/4] net: mitigating kmem_cache slowpath for network stack in NAPI context Date: Fri, 23 Oct 2015 14:46:01 +0200 [thread overview] Message-ID: <20151023124451.17364.14594.stgit@firesoul> (raw) It have been a long road. Back in July 2014 I realized that network stack were hitting the kmem_cache/SLUB slowpath when freeing SKBs, but had no solution. In Dec 2014 I had implemented a solution called qmempool[1], that showed it was possible to improve this, but got rejected due to being a cache on top of kmem_cache. In July 2015 improvements to kmem_cache were proposed, and recently Oct 2015 my kmem_cache (SLAB+SLUB) patches for bulk alloc and free have been accepted into the AKPM quilt tree. This patchset is the first real use-case kmem_cache bulk alloc and free. And is joint work with Alexander Duyck while still at Red Hat. Using bulk free to avoid the SLUB slowpath shows the full potential. In this patchset it is realized in NAPI/softirq context. 1. During DMA TX completion bulk free is optimal and does not introduce any added latency. 2. bulk free of SKBs delay free'ed due to IRQ context in net_tx_action softirq completion queue. Using bulk alloc is showing minor improvements for SLUB(+0.9%), but a very slight slowdown for SLAB(-0.1%). [1] http://thread.gmane.org/gmane.linux.network/342347/focus=126138 This patchset is based on net-next (commit 26440c835), BUT I've applied several patches from AKPMs MM-tree. Cherrypick some commits from MMOTM tree on branch/tag mmotm-2015-10-06-16-30 from git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git (Below commit IDs are obviously not stable) Pickup my own MM-changes: b0aa3e95ce82 ("slub: mark the dangling ifdef #else of CONFIG_SLUB_DEBUG") 114a2b37847c ("slab: implement bulking for SLAB allocator") 606397476e8b ("slub: support for bulk free with SLUB freelists") ee29cd6a570c ("slub: optimize bulk slowpath free by detached freelist") 491c6e0ca89d ("slub-optimize-bulk-slowpath-free-by-detached-freelist-fix") Pickup slab.h changes: d9a47e0b776b ("compiler.h: add support for function attribute assume_aligned") 1c3a5c789b4f ("slab.h: sprinkle __assume_aligned attributes") Wanted Kirill A. Shutemov's changes as they change virt_to_head_page(), had to apply patches manually from http://ozlabs.org/~akpm/mmotm/ (stamp-2015-10-20-16-33) as AKPM made several small fixes. --- Jesper Dangaard Brouer (4): net: bulk free infrastructure for NAPI context, use napi_consume_skb net: bulk free SKBs that were delay free'ed due to IRQ context ixgbe: bulk free SKBs during TX completion cleanup cycle net: bulk alloc and reuse of SKBs in NAPI context drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 + include/linux/skbuff.h | 4 + net/core/dev.c | 9 ++ net/core/skbuff.c | 122 +++++++++++++++++++++++-- 4 files changed, 127 insertions(+), 14 deletions(-) -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com> To: netdev@vger.kernel.org Cc: Alexander Duyck <alexander.duyck@gmail.com>, linux-mm@kvack.org, Jesper Dangaard Brouer <brouer@redhat.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Christoph Lameter <cl@linux.com> Subject: [PATCH 0/4] net: mitigating kmem_cache slowpath for network stack in NAPI context Date: Fri, 23 Oct 2015 14:46:01 +0200 [thread overview] Message-ID: <20151023124451.17364.14594.stgit@firesoul> (raw) It have been a long road. Back in July 2014 I realized that network stack were hitting the kmem_cache/SLUB slowpath when freeing SKBs, but had no solution. In Dec 2014 I had implemented a solution called qmempool[1], that showed it was possible to improve this, but got rejected due to being a cache on top of kmem_cache. In July 2015 improvements to kmem_cache were proposed, and recently Oct 2015 my kmem_cache (SLAB+SLUB) patches for bulk alloc and free have been accepted into the AKPM quilt tree. This patchset is the first real use-case kmem_cache bulk alloc and free. And is joint work with Alexander Duyck while still at Red Hat. Using bulk free to avoid the SLUB slowpath shows the full potential. In this patchset it is realized in NAPI/softirq context. 1. During DMA TX completion bulk free is optimal and does not introduce any added latency. 2. bulk free of SKBs delay free'ed due to IRQ context in net_tx_action softirq completion queue. Using bulk alloc is showing minor improvements for SLUB(+0.9%), but a very slight slowdown for SLAB(-0.1%). [1] http://thread.gmane.org/gmane.linux.network/342347/focus=126138 This patchset is based on net-next (commit 26440c835), BUT I've applied several patches from AKPMs MM-tree. Cherrypick some commits from MMOTM tree on branch/tag mmotm-2015-10-06-16-30 from git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git (Below commit IDs are obviously not stable) Pickup my own MM-changes: b0aa3e95ce82 ("slub: mark the dangling ifdef #else of CONFIG_SLUB_DEBUG") 114a2b37847c ("slab: implement bulking for SLAB allocator") 606397476e8b ("slub: support for bulk free with SLUB freelists") ee29cd6a570c ("slub: optimize bulk slowpath free by detached freelist") 491c6e0ca89d ("slub-optimize-bulk-slowpath-free-by-detached-freelist-fix") Pickup slab.h changes: d9a47e0b776b ("compiler.h: add support for function attribute assume_aligned") 1c3a5c789b4f ("slab.h: sprinkle __assume_aligned attributes") Wanted Kirill A. Shutemov's changes as they change virt_to_head_page(), had to apply patches manually from http://ozlabs.org/~akpm/mmotm/ (stamp-2015-10-20-16-33) as AKPM made several small fixes. --- Jesper Dangaard Brouer (4): net: bulk free infrastructure for NAPI context, use napi_consume_skb net: bulk free SKBs that were delay free'ed due to IRQ context ixgbe: bulk free SKBs during TX completion cleanup cycle net: bulk alloc and reuse of SKBs in NAPI context drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 + include/linux/skbuff.h | 4 + net/core/dev.c | 9 ++ net/core/skbuff.c | 122 +++++++++++++++++++++++-- 4 files changed, 127 insertions(+), 14 deletions(-) -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2015-10-23 12:46 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-23 12:46 Jesper Dangaard Brouer [this message] 2015-10-23 12:46 ` [PATCH 0/4] net: mitigating kmem_cache slowpath for network stack in NAPI context Jesper Dangaard Brouer 2015-10-23 12:46 ` [PATCH 1/4] net: bulk free infrastructure for NAPI context, use napi_consume_skb Jesper Dangaard Brouer 2015-10-23 12:46 ` Jesper Dangaard Brouer 2015-10-23 12:46 ` [PATCH 2/4] net: bulk free SKBs that were delay free'ed due to IRQ context Jesper Dangaard Brouer 2015-10-23 12:46 ` [PATCH 3/4] ixgbe: bulk free SKBs during TX completion cleanup cycle Jesper Dangaard Brouer 2015-10-23 12:46 ` Jesper Dangaard Brouer 2015-10-23 12:46 ` [PATCH 4/4] net: bulk alloc and reuse of SKBs in NAPI context Jesper Dangaard Brouer 2015-10-27 1:09 ` [PATCH 0/4] net: mitigating kmem_cache slowpath for network stack " David Miller 2016-02-02 21:11 ` [net-next PATCH 00/11] net: mitigating kmem_cache slowpath and BoF discussion patches Jesper Dangaard Brouer 2016-02-02 21:11 ` [net-next PATCH 01/11] net: bulk free infrastructure for NAPI context, use napi_consume_skb Jesper Dangaard Brouer 2016-02-02 21:11 ` [net-next PATCH 02/11] net: bulk free SKBs that were delay free'ed due to IRQ context Jesper Dangaard Brouer 2016-02-02 21:11 ` [net-next PATCH 03/11] ixgbe: bulk free SKBs during TX completion cleanup cycle Jesper Dangaard Brouer 2016-02-02 21:12 ` [net-next PATCH 04/11] net: bulk alloc and reuse of SKBs in NAPI context Jesper Dangaard Brouer 2016-02-03 0:52 ` Alexei Starovoitov 2016-02-03 10:38 ` Jesper Dangaard Brouer 2016-02-02 21:12 ` [net-next PATCH 05/11] mlx5: use napi_*_skb APIs to get bulk alloc and free Jesper Dangaard Brouer 2016-02-02 21:13 ` [net-next PATCH 06/11] RFC: mlx5: RX bulking or bundling of packets before calling network stack Jesper Dangaard Brouer 2016-02-09 11:57 ` Saeed Mahameed 2016-02-10 20:26 ` Jesper Dangaard Brouer 2016-02-16 0:01 ` Saeed Mahameed 2016-02-02 21:13 ` [net-next PATCH 07/11] net: introduce napi_alloc_skb_hint() for more use-cases Jesper Dangaard Brouer 2016-02-02 22:29 ` kbuild test robot 2016-02-02 21:14 ` [net-next PATCH 08/11] mlx5: hint the NAPI alloc skb API about the expected bulk size Jesper Dangaard Brouer 2016-02-02 21:14 ` [net-next PATCH 09/11] RFC: dummy: bulk free SKBs Jesper Dangaard Brouer 2016-02-02 21:15 ` [net-next PATCH 10/11] RFC: net: API for RX handover of multiple SKBs to stack Jesper Dangaard Brouer 2016-02-02 21:15 ` [net-next PATCH 11/11] RFC: net: RPS bulk enqueue to backlog Jesper Dangaard Brouer 2016-02-07 19:25 ` [net-next PATCH 00/11] net: mitigating kmem_cache slowpath and BoF discussion patches David Miller 2016-02-08 12:14 ` [net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath Jesper Dangaard Brouer 2016-02-08 12:14 ` Jesper Dangaard Brouer 2016-02-08 12:14 ` [net-next PATCH V2 1/3] net: bulk free infrastructure for NAPI context, use napi_consume_skb Jesper Dangaard Brouer 2016-02-08 12:15 ` [net-next PATCH V2 2/3] net: bulk free SKBs that were delay free'ed due to IRQ context Jesper Dangaard Brouer 2016-02-08 12:15 ` [net-next PATCH V2 3/3] ixgbe: bulk free SKBs during TX completion cleanup cycle Jesper Dangaard Brouer 2016-02-11 16:59 ` [net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath David Miller 2016-02-13 11:12 ` Tilman Schmidt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20151023124451.17364.14594.stgit@firesoul \ --to=brouer@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=alexander.duyck@gmail.com \ --cc=cl@linux.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=linux-mm@kvack.org \ --cc=netdev@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.