From: Matthew Wilcox <willy@infradead.org>
To: Namjae Jeon <namjae.jeon@samsung.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-cifs@vger.kernel.org,
linux-cifsd-devel@lists.sourceforge.net, smfrench@gmail.com,
senozhatsky@chromium.org, hyc.lee@gmail.com,
viro@zeniv.linux.org.uk, hch@lst.de, hch@infradead.org,
ronniesahlberg@gmail.com, aurelien.aptel@gmail.com,
aaptel@suse.com, sandeen@sandeen.net, dan.carpenter@oracle.com,
colin.king@canonical.com, rdunlap@infradead.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steve French <stfrench@microsoft.com>
Subject: Re: [PATCH 3/5] cifsd: add file operations
Date: Mon, 22 Mar 2021 08:15:12 +0000 [thread overview]
Message-ID: <20210322081512.GI1719932@casper.infradead.org> (raw)
In-Reply-To: <20210322051344.1706-4-namjae.jeon@samsung.com>
On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> This adds file operations and buffer pool for cifsd.
Why do you want this buffer pool? Do you not trust the
slab allocator to be able to do its job? Because what you have
here looks slower than the slab allocator.
Let's follow this through for the best-case scenario (a buffer of the right
size already exists):
> +void *ksmbd_find_buffer(size_t size)
> +{
> + struct wm *wm;
> +
> + wm = find_wm(size);
> +
> + WARN_ON(!wm);
> + if (wm)
> + return wm->buffer;
> + return NULL;
> +}
OK, simple, we just call find_wm().
> +static struct wm *find_wm(size_t size)
> +{
> + struct wm_list *wm_list;
> + struct wm *wm;
> +
> + wm_list = match_wm_list(size);
First we find the list for this buffer ...
> +static struct wm_list *match_wm_list(size_t size)
> +{
> + struct wm_list *l, *rl = NULL;
> +
> + read_lock(&wm_lists_lock);
> + list_for_each_entry(l, &wm_lists, list) {
> + if (l->sz == size) {
> + rl = l;
> + break;
> + }
> + }
> + read_unlock(&wm_lists_lock);
> + return rl;
> +}
... by taking an rwlock, and walking a linked list?! Uh ...
> + while (1) {
> + spin_lock(&wm_list->wm_lock);
> + if (!list_empty(&wm_list->idle_wm)) {
> + wm = list_entry(wm_list->idle_wm.next,
> + struct wm,
> + list);
> + list_del(&wm->list);
> + spin_unlock(&wm_list->wm_lock);
> + return wm;
Great! We found one! And all it cost us was acquiring a global rwlock,
walking a linked list to find a wmlist, then a per-wmlist spinlock.
Meanwhile, there's no guarantee the buffer we found is on the local
NUMA node.
Compare to slub, allocating from a kmem_cache (assuming you create
one for each buffer size ...):
void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags)
void *ret = slab_alloc(s, gfpflags, _RET_IP_, s->object_size);
static __always_inline void *slab_alloc(struct kmem_cache *s,
gfp_t gfpflags, unsigned long addr, size_t orig_size)
return slab_alloc_node(s, gfpflags, NUMA_NO_NODE, addr, orig_size);
static __always_inline void *slab_alloc_node(struct kmem_cache *s,
gfp_t gfpflags, int node, unsigned long addr, size_t orig_size)
do {
tid = this_cpu_read(s->cpu_slab->tid);
c = raw_cpu_ptr(s->cpu_slab);
} while (IS_ENABLED(CONFIG_PREEMPTION) &&
unlikely(tid != READ_ONCE(c->tid)));
object = c->freelist;
page = c->page;
if (unlikely(!object || !page || !node_match(page, node))) {
object = __slab_alloc(s, gfpflags, node, addr, c);
} else {
void *next_object = get_freepointer_safe(s, object);
if (unlikely(!this_cpu_cmpxchg_double(
s->cpu_slab->freelist, s->cpu_slab->tid,
object, tid,
next_object, next_tid(tid)))) {
note_cmpxchg_failure("slab_alloc", s, tid);
goto redo;
}
prefetch_freepointer(s, next_object);
stat(s, ALLOC_FASTPATH);
No lock, anywhere. Lots of percpu goodness, so you get memory allocated
on your local node.
What's the scenario for which your allocator performs better than slub,
on a typical machine that serves enough SMB that it's worth having an
in-kernel SMBD?
next prev parent reply other threads:[~2021-03-22 8:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20210322052203epcas1p21fe2d04c4df5396c466c38f4d57d8bb8@epcas1p2.samsung.com>
2021-03-22 5:13 ` [PATCH 0/5] cifsd: introduce new SMB3 kernel server Namjae Jeon
[not found] ` <CGME20210322052204epcas1p1382cadbfe958d156c0ad9f7fcb8532b7@epcas1p1.samsung.com>
2021-03-22 5:13 ` [PATCH 1/5] cifsd: add server handler and tranport layers Namjae Jeon
2021-03-22 22:18 ` Matthew Wilcox
2021-03-23 3:01 ` Namjae Jeon
2021-03-23 3:12 ` Matthew Wilcox
2021-03-23 3:16 ` Namjae Jeon
[not found] ` <CGME20210322052206epcas1p438f15851216f07540537c5547a0a2c02@epcas1p4.samsung.com>
2021-03-22 5:13 ` [PATCH 2/5] cifsd: add server-side procedures for SMB3 Namjae Jeon
2021-03-22 6:47 ` Dan Carpenter
2021-03-22 6:50 ` Christoph Hellwig
2021-03-22 13:25 ` [Linux-cifsd-devel] " Stefan Metzmacher
2021-03-22 23:20 ` Namjae Jeon
2021-03-22 23:17 ` Namjae Jeon
2021-03-23 7:19 ` Dan Carpenter
2021-03-25 5:25 ` Sebastian Gottschall
2021-03-22 8:34 ` Matthew Wilcox
2021-03-22 10:27 ` Sergey Senozhatsky
2021-03-22 13:12 ` Matthew Wilcox
[not found] ` <CGME20210322052207epcas1p3f0a5bdfd2c994a849a67b465479d0721@epcas1p3.samsung.com>
2021-03-22 5:13 ` [PATCH 3/5] cifsd: add file operations Namjae Jeon
2021-03-22 6:55 ` Al Viro
2021-03-23 0:12 ` Namjae Jeon
2021-03-22 7:02 ` Al Viro
2021-03-22 9:26 ` Sergey Senozhatsky
2021-03-22 7:04 ` Dan Carpenter
2021-03-22 9:39 ` Sergey Senozhatsky
2021-03-22 8:15 ` Matthew Wilcox [this message]
2021-03-22 9:03 ` Sergey Senozhatsky
2021-03-22 13:02 ` Matthew Wilcox
2021-03-22 13:57 ` Christoph Hellwig
2021-03-22 14:40 ` Matthew Wilcox
2021-03-22 17:09 ` Matthew Wilcox
2021-03-23 0:05 ` Sergey Senozhatsky
2021-03-22 16:16 ` Schaufler, Casey
2021-03-23 0:21 ` Namjae Jeon
[not found] ` <CGME20210322052208epcas1p430b2e93761d5194844c533c61d43242d@epcas1p4.samsung.com>
2021-03-22 5:13 ` [PATCH 4/5] cifsd: add Kconfig and Makefile Namjae Jeon
[not found] ` <CGME20210322052209epcas1p377f1542bcc9ec50219d2e57aa92d944b@epcas1p3.samsung.com>
2021-03-22 5:13 ` [PATCH 5/5] MAINTAINERS: add cifsd kernel server Namjae Jeon
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=20210322081512.GI1719932@casper.infradead.org \
--to=willy@infradead.org \
--cc=aaptel@suse.com \
--cc=aurelien.aptel@gmail.com \
--cc=colin.king@canonical.com \
--cc=dan.carpenter@oracle.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=hyc.lee@gmail.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-cifsd-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=rdunlap@infradead.org \
--cc=ronniesahlberg@gmail.com \
--cc=sandeen@sandeen.net \
--cc=senozhatsky@chromium.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=smfrench@gmail.com \
--cc=stfrench@microsoft.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).