From: Dominique Martinet <asmadeus@codewreck.org>
To: Kent Overstreet <kent.overstreet@gmail.com>,
Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: linux-kernel@vger.kernel.org,
v9fs-developer@lists.sourceforge.net,
Eric Van Hensbergen <ericvh@gmail.com>,
Latchesar Ionkov <lucho@ionkov.net>
Subject: Re: [PATCH 3/3] 9p: Add mempools for RPCs
Date: Mon, 4 Jul 2022 12:38:46 +0900 [thread overview]
Message-ID: <YsJgxoTyYxX1NwyW@codewreck.org> (raw)
In-Reply-To: <20220704030557.fm7xecylcq4z4zkr@moria.home.lan>
+Christian, sorry I just noticed you weren't in Ccs again --
the patches are currently there if you want a look:
https://evilpiepirate.org/git/bcachefs.git/log/?h=9p_mempool
I think it'll conflict a bit with your 8k non-read/write RPCs but I'll
take care of that when checking it this weekend.
Kent Overstreet wrote on Sun, Jul 03, 2022 at 11:05:57PM -0400:
> > We shouldn't have any user calling with more at this point (the
> > user-provided size comes from p9_client_prepare_req arguments and it's
> > either msize or header size constants); and it probably makes sense to
> > check and error out rather than cap it.
>
> If that's the case I think we should just switch the warning to a BUG_ON() - I
> just wasn't sure from reading the code if that was really guarded against.
yes, BUG_ON is good for me.
> > > - if (p9_fcall_init(c, &req->tc, alloc_msize))
> > > + if (p9_fcall_init(c, &req->tc, 0, alloc_msize))
> > > goto free_req;
> > > - if (p9_fcall_init(c, &req->rc, alloc_msize))
> > > + if (p9_fcall_init(c, &req->rc, 1, alloc_msize))
> >
> > given the two rc/tc buffers are of same size I don't see the point of
> > using two caches either, you could just double the min number of
> > elements to the same effect?
>
> You can't double allocate from the same mempool, that will deadlock if multiple
> threads need the last element at the same time - I should've left a comment for
> that.
hmm, looking at the code as long as min elements is big enough the
deadlock becomes increasingly difficult to hit -- but I guess there's no
guarantee we won't get 8 threads each getting their first item from the
pool and starving each other on the second... Fair enough, thank you for
the comment.
> @@ -270,10 +276,8 @@ p9_tag_alloc(struct p9_client *c, int8_t type, unsigned int max_size)
> if (!req)
> return ERR_PTR(-ENOMEM);
>
> - if (p9_fcall_init(c, &req->tc, alloc_msize))
> - goto free_req;
> - if (p9_fcall_init(c, &req->rc, alloc_msize))
> - goto free;
> + p9_fcall_init(c, &req->tc, 0, alloc_msize);
> + p9_fcall_init(c, &req->rc, 1, alloc_msize);
mempool allocation never fails, correct?
(don't think this needs a comment, just making sure here)
This all looks good to me, will queue it up in my -next branch after
running some tests next weekend and hopefully submit when 5.20 opens
with the code making smaller allocs more common.
--
Dominique
next prev parent reply other threads:[~2022-07-04 3:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-04 1:09 [merged mm-stable] tools-add-memcg_shrinkerpy.patch removed from -mm tree Andrew Morton
2022-07-04 1:42 ` [PATCH 1/3] 9p: Drop kref usage Kent Overstreet
2022-07-04 1:42 ` [PATCH 2/3] 9p: Add client parameter to p9_req_put() Kent Overstreet
2022-07-04 1:42 ` [PATCH 3/3] 9p: Add mempools for RPCs Kent Overstreet
2022-07-04 2:22 ` Dominique Martinet
2022-07-04 3:05 ` Kent Overstreet
2022-07-04 3:38 ` Dominique Martinet [this message]
2022-07-04 3:52 ` Kent Overstreet
2022-07-04 11:12 ` Christian Schoenebeck
2022-07-04 13:06 ` Dominique Martinet
2022-07-04 13:56 ` Christian Schoenebeck
2022-07-09 7:43 ` Dominique Martinet
2022-07-09 14:21 ` Christian Schoenebeck
2022-07-09 14:42 ` Dominique Martinet
2022-07-09 18:08 ` Christian Schoenebeck
2022-07-09 20:50 ` Dominique Martinet
2022-07-10 12:57 ` Christian Schoenebeck
2022-07-10 13:19 ` Dominique Martinet
2022-07-10 15:16 ` Christian Schoenebeck
2022-07-13 4:17 ` [RFC PATCH] 9p: forbid use of mempool for TFLUSH Dominique Martinet
2022-07-13 6:39 ` Kent Overstreet
2022-07-13 7:12 ` Dominique Martinet
2022-07-13 7:40 ` Kent Overstreet
2022-07-13 8:18 ` Dominique Martinet
2022-07-14 19:16 ` Christian Schoenebeck
2022-07-14 22:31 ` Dominique Martinet
2022-07-15 10:23 ` Christian Schoenebeck
2022-07-04 13:06 ` [PATCH 3/3] 9p: Add mempools for RPCs Kent Overstreet
2022-07-04 13:39 ` Christian Schoenebeck
2022-07-04 14:19 ` Kent Overstreet
2022-07-05 9:59 ` Christian Schoenebeck
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=YsJgxoTyYxX1NwyW@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=ericvh@gmail.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=v9fs-developer@lists.sourceforge.net \
/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 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.