Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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
Message-ID: <2335194.JbyEHpbE5P@silver>
In-Reply-To: <YsJgxoTyYxX1NwyW@codewreck.org>
References: <20220704010945.C230AC341C7@smtp.kernel.org>
 <20220704030557.fm7xecylcq4z4zkr@moria.home.lan>
 <YsJgxoTyYxX1NwyW@codewreck.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

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