Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp989153imm; Wed, 1 Aug 2018 08:26:09 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcQWHkQ4wW4GMrZdOdtYCbGaB2mP3i3ViL7Am6p07+AfXOU+qCBBy4XAvtkM0y0ihnE2Xgv X-Received: by 2002:a17:902:8a87:: with SMTP id p7-v6mr24853336plo.281.1533137169910; Wed, 01 Aug 2018 08:26:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533137169; cv=none; d=google.com; s=arc-20160816; b=pMsYc8Jy28IlI/e3D2bizd80lHSj0kL/okTO4C/6jGb29rVW8f7NzP8CuDnbRvLW5g h8/dZURZY0RarBs3vLtzPDStTICjhYrtsuAJxyNF9TZHdIDzMHtdV8KCQtoIY6eP6vW2 9urKQBBkZfEapow25Nl0m8ll36lhz6GvdD6P5DMqjZyqypGeu58wU8y4ogjW3dPCubKA 7mZcDu22RIyw9pdeyi212z1KZ6laaIRgTG9aGMCdNyBHE3yRDmba8X7Pq+hCQutBsFZi 4kbMqYHAvokk7Fdcxr7ZfcRGJYpHGqiMd7t2RVZozuRBMQhvh4PvI2ABUERqPs5Rm/1l 1gJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=50JYfqyKbO3LDZwduoZHh1eob2Ov0HI2258r7MbpNTg=; b=hxPftpOvSaL2vd53G/4m+8mxy6bruyPFolD6h4fmKDKDX9s8zlQW7ZVBK7KADifcYA YPqw862lh7kxPwyy3GpV5NZYujKm4YNmE0yO00ueHkzrj7KPrmIkuwarCLY0KSAf37dv /0CsF9fmizQmDKFd9VUkv8ZAtddskaJwO6p+nBwalStQgUbdOalj5XHtXn+0PYriyFkF naUWO9pH8hYkTJBPa7p/b1Zw8IAy4kph7koMtUNoXxl8fbujonbFKEC54SUWivujvUlY xNUdvqBz/HhqJtk/wexBKqF1y0Ceqt/FzDtvKNkatIv6o4Tqv3csooSmOIc1egSb31/t HqVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r7-v6si10903136ple.309.2018.08.01.08.25.31; Wed, 01 Aug 2018 08:26:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389771AbeHARJS (ORCPT + 99 others); Wed, 1 Aug 2018 13:09:18 -0400 Received: from nautica.notk.org ([91.121.71.147]:47528 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389627AbeHARJS (ORCPT ); Wed, 1 Aug 2018 13:09:18 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id DDBE3C009; Wed, 1 Aug 2018 17:23:03 +0200 (CEST) Date: Wed, 1 Aug 2018 17:22:48 +0200 From: Dominique Martinet To: Greg Kurz Cc: v9fs-developer@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Matthew Wilcox , linux-kernel@vger.kernel.org Subject: Re: [V9fs-developer] [PATCH 2/2] net/9p: add a per-client fcall kmem_cache Message-ID: <20180801152248.GB21463@nautica> References: <20180730093101.GA7894@nautica> <1532943263-24378-1-git-send-email-asmadeus@codewreck.org> <1532943263-24378-2-git-send-email-asmadeus@codewreck.org> <20180801162824.31fb6a30@bahia.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180801162824.31fb6a30@bahia.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greg Kurz wrote on Wed, Aug 01, 2018: > > diff --git a/net/9p/client.c b/net/9p/client.c > > index ba99a94a12c9..215e3b1ed7b4 100644 > > --- a/net/9p/client.c > > +++ b/net/9p/client.c > > @@ -231,15 +231,34 @@ static int parse_opts(char *opts, struct p9_client *clnt) > > return ret; > > } > > > > -static int p9_fcall_alloc(struct p9_fcall *fc, int alloc_msize) > > +static int p9_fcall_alloc(struct p9_client *c, struct p9_fcall *fc, > > + int alloc_msize) > > { > > - fc->sdata = kmalloc(alloc_msize, GFP_NOFS); > > + if (c->fcall_cache && alloc_msize == c->msize) > > This is a presumably hot path for any request but the initial TVERSION, > you probably want likely() here... c->fcall_cache is indeed very likely, but alloc_size == c->msize not so much, as zc requests will be quite common for virtio and will be 4k in size. Although with that cache I'm starting to wonder if we should always use it... Speed-wise if there is no memory pressure the cache is likely going to be faster. If there is pressure and the items are reclaimed though that'll bring some heavier slow-down as it'll need to find bigger memory regions. I'm not sure which path we should favor, tbh. I'll keep these separate for now. For the first part of the check, Matthew suggested trying to trick msize into a different value to fail this check for the initial TVERSION call, but even after thinking it a bit I don't really see how to do that cleanly. I can at least make -that- likely()... > > > + fc->sdata = kmem_cache_alloc(c->fcall_cache, GFP_NOFS); > > + else > > + fc->sdata = kmalloc(alloc_msize, GFP_NOFS); > > if (!fc->sdata) > > return -ENOMEM; > > fc->capacity = alloc_msize; > > return 0; > > } > > > > +void p9_fcall_free(struct p9_client *c, struct p9_fcall *fc) > > +{ > > + /* sdata can be NULL for interrupted requests in trans_rdma, > > + * and kmem_cache_free does not do NULL-check for us > > + */ > > + if (unlikely(!fc->sdata)) > > + return; > > + > > + if (c->fcall_cache && fc->capacity == c->msize) > > ... and here as well. For this one I'll unfortunately need to store in the fc how it has been allocated as slob doesn't allow to kmem_cache_free() a buffer allocated by kmalloc and in prevision of refs being refcounted in a hostile world the initial TVERSION req could be freed after fcall_cache is created :/ That's a bit of a burden but at least will reduce the checks to one here > > + kmem_cache_free(c->fcall_cache, fc->sdata); > > + else > > + kfree(fc->sdata); > > +} > > +EXPORT_SYMBOL(p9_fcall_free); > > + > > static struct kmem_cache *p9_req_cache; > > > > /** Anyway I've had as many comments as I could hope for, thanks everyone for the quick review. I'll send a v2 of both patches tomorrow -- Dominique