mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kangmin Park <l4stpr0gr4m@gmail.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Alexander Lobakin <alobakin@pm.me>,
	Jonathan Lemon <jonathan.lemon@gmail.com>,
	Willem de Bruijn <willemb@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Guillaume Nault <gnault@redhat.com>,
	Vasily Averin <vvs@virtuozzo.com>,
	Cong Wang <cong.wang@bytedance.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH net-next] Introducing lockless cache built on top of slab allocator
Date: Tue, 21 Sep 2021 02:47:13 +0900	[thread overview]
Message-ID: <20210920174713.4998-1-l4stpr0gr4m@gmail.com> (raw)

It is just introducing and proof of concept.
The patch code is based on other RFC patches. So, the code is not
correct yet, it is just simple proof of concept.

Recently block layer implemented percpu, lockless cache on the top
of slab allocator. It can be used for IO polling.

Link: https://lwn.net/Articles/868070/
Link: https://www.spinics.net/lists/linux-block/msg71964.html

It gained some IOPS increase (performance increased by about 10%
on the block layer).

And there are attempts to implement the percpu, lockless cache.

Link: https://lore.kernel.org/linux-mm/20210920154816.31832-1-42.hyeyoo@gmail.com/T/#u

If this cache is implemented successfully,
how about use this cache to allocate skb instead of kmem_cache_alloc_bulk()
in napi_skb_cache_get()?

I want your comment/opinion.

Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com>
---
 net/core/skbuff.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7c2ab27fcbf9..f9a9deca423d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -170,11 +170,15 @@ static struct sk_buff *napi_skb_cache_get(void)
 	struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache);
 	struct sk_buff *skb;
 
-	if (unlikely(!nc->skb_count))
-		nc->skb_count = kmem_cache_alloc_bulk(skbuff_head_cache,
-						      GFP_ATOMIC,
-						      NAPI_SKB_CACHE_BULK,
-						      nc->skb_cache);
+	if (unlikely(!nc->skb_count)) {
+		/* kmem_cache_alloc_cached should be changed to return the size of
+		 * the allocated cache
+		 */
+		nc->skb_cache = kmem_cache_alloc_cached(skbuff_head_cache,
+							GFP_ATOMIC | SLB_LOCKLESS_CACHE);
+		nc->skb_count = this_cpu_ptr(skbuff_head_cache)->size;
+	}
+
 	if (unlikely(!nc->skb_count))
 		return NULL;
 
-- 
2.26.2


             reply	other threads:[~2021-09-20 23:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 17:47 Kangmin Park [this message]
2021-09-20 20:50 ` Jakub Kicinski
2021-09-21  1:48   ` Kangmin Park

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=20210920174713.4998-1-l4stpr0gr4m@gmail.com \
    --to=l4stpr0gr4m@gmail.com \
    --cc=alobakin@pm.me \
    --cc=cong.wang@bytedance.com \
    --cc=davem@davemloft.net \
    --cc=gnault@redhat.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=vvs@virtuozzo.com \
    --cc=willemb@google.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®