From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Kent Overstreet <kent.overstreet@gmail.com>,
Dominique Martinet <asmadeus@codewreck.org>
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, 04 Jul 2022 13:12:51 +0200 [thread overview]
Message-ID: <2335194.JbyEHpbE5P@silver> (raw)
In-Reply-To: <YsJgxoTyYxX1NwyW@codewreck.org>
On Montag, 4. Juli 2022 05:38:46 CEST Dominique Martinet wrote:
> +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 wonder whether it would make sense to update 9p section in MAINTAINERS to
better reflect current reality, at least in a way such that contributors would
CC me right away?
Eric, Latchesar, what do you think?
> > @@ -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.
Hoo, Dominique, please hold your horses. I currently can't keep up with
reviewing and testing all pending 9p patches right now.
Personally I would hold these patches back for now. They would make sense on
current situation on master, because ATM basically all 9p requests simply
allocate exactly 'msize' for any 9p request.
However that's exactly what I was going to address with my already posted
patches (relevant patches regarding this issue here being 9..12):
https://lore.kernel.org/all/cover.1640870037.git.linux_oss@crudebyte.com/
And in the cover letter (section "STILL TODO" ... "3.") I was suggesting to
subsequently subdivide kmem_cache_alloc() into e.g. 4 allocation size
categories? Because that's what my already posted patches do anyway.
How about I address the already discussed issues and post a v5 of those
patches this week and then we can continue from there?
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2022-07-04 11:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220704010945.C230AC341C7@smtp.kernel.org>
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
2022-07-04 3:52 ` Kent Overstreet
2022-07-04 11:12 ` Christian Schoenebeck [this message]
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=2335194.JbyEHpbE5P@silver \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=ericvh@gmail.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox