Message ID | 20240201081935.200031-1-chentao@kylinos.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-47770-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2719:b0:106:209c:c626 with SMTP id hl25csp227dyb; Thu, 1 Feb 2024 00:20:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IEuKA8//jbvKUuJKdffj9tCAZlWnUFlhpPwusVtL1e7qmVL/VoQRPWwwy3egFT7PmoW6JmU X-Received: by 2002:a17:90a:eac4:b0:296:207b:c917 with SMTP id ev4-20020a17090aeac400b00296207bc917mr224746pjb.23.1706775606856; Thu, 01 Feb 2024 00:20:06 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706775606; cv=pass; d=google.com; s=arc-20160816; b=M77Qto+u++MHrdcHcf1OcnRnACLDK/NtI7cQCgKUqQmK/a722+OrNgeecpkAfpyy34 RZ2Uc1VBmfo1K6O59HGCkLRzvc3ch/+UEoAGXHP8Lf8ghL2TgfA70B7c0wZLR3C6eTjD zCTrQdwm5JUX6y/uxC2mU0jklbbkTz/NTa1Z90CPwk0DRefyiiywmL2umG2MPXYeMHeY 7L54HbUkIZg6SJHyllk6KezVkOebuI4n5Z3OPN2NObtl0xVE/gLTd4fVQw/zMp3ixo7q IYdIfMlipaN2EU3TC2ZtD/EXNgv/ccCUqHsRTpbJxUsz1cCucgtczp4wP6qChCAviuIi buNg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=aAj30P+UldIhmM/VXg0uWVvch1Rd1k+ViY2P/yiQhs8=; fh=i/XoBTRSp2Yq/YGPYNmUuK2DjsWBx7/H8+1lvdPiU9U=; b=0+9ND2Y1KyNYG03NtNPs2+/2T5ihGIzt6J0X5WKdccs+HG/wYwHLs3aaq89uVbSiLI 9D4BtQGJkpVGVRXR4sVy4NCSB/jK5ruhMMlAszeqegI4s69tvMn7mYjBt9SO7z73Lpfb tIZrdx47TCdVVel8DU2eoVgVfvUAfoA3Iuo8YzlUNLR2txNAWmKG2AQK+0JpA8eCGB6T C/vEiPdOm6lPlgt0ea745dAaJbAy1SoRfmVvRXBaaptQuJnuLecGGM5MPSmNPonGkZqj kEqIPl/SVxGwmQo5dVk4q3HoWZeSfSjmobZ6qVOiu5GeRZWzZzYMXJW3VO/e/sNEOnz1 qRPw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=kylinos.cn); spf=pass (google.com: domain of linux-kernel+bounces-47770-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-47770-ouuuleilei=gmail.com@vger.kernel.org" X-Forwarded-Encrypted: i=1; AJvYcCUcDpgBC+a7Rh3bolGhcGh8BUJVTT787y08JYwhnPzhu1MwBPh9rGRTNwh/lTyk3bTU98AOM7ScFfiIDVXwxuTN+mkxhQ== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id h21-20020a17090aa89500b0028e6d898ff4si3134481pjq.30.2024.02.01.00.20.06 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 00:20:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-47770-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=kylinos.cn); spf=pass (google.com: domain of linux-kernel+bounces-47770-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-47770-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 9FB50285ED6 for <ouuuleilei@gmail.com>; Thu, 1 Feb 2024 08:20:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D190D15959C; Thu, 1 Feb 2024 08:19:52 +0000 (UTC) Received: from mailgw.kylinos.cn (mailgw.kylinos.cn [124.126.103.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25C39158D76; Thu, 1 Feb 2024 08:19:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=124.126.103.232 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706775591; cv=none; b=iAnXxhQSTL20GBZ2Awcmhqf43KKrM43GigNROtdi6OTmVFJnGHQtamKY0KYdfnCiAPuLAjUh/bA1tSAp6gvsuEMjrq+GJeq7Urju80R17T7DgoCgdOGdkXPPhX50G21ihOoas93+KQfqO1pEkSA5Flxvt8103+sr11l4znMsEiQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706775591; c=relaxed/simple; bh=dpj7BQrTh0UjOXplbKxWBBtt23WR/YSUKBByrVjv5Nw=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=YrMUXOS07S0Q7WPqlIQVChb2MbYeMeFzohU7NUmvJg9Jr/hp0VorxtLbHapNRHIQC6/lpANbaB6xgMpAIUrW/WQ/ETJGfbNLwWLc2xbi4p0TtXq8sPNYt2h42S3ikIGay7+5No/sC4m63b20BlVSwRagMIbTN/4NsHaTUL2VIBY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn; spf=pass smtp.mailfrom=kylinos.cn; arc=none smtp.client-ip=124.126.103.232 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kylinos.cn X-UUID: 37791ac224ac437d8b6e2347458ab69e-20240201 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.35,REQID:2050252c-341c-4a4e-8f25-f548989288d7,IP:10, URL:0,TC:0,Content:0,EDM:25,RT:0,SF:-15,FILE:0,BULK:0,RULE:Release_Ham,ACT ION:release,TS:20 X-CID-INFO: VERSION:1.1.35,REQID:2050252c-341c-4a4e-8f25-f548989288d7,IP:10,UR L:0,TC:0,Content:0,EDM:25,RT:0,SF:-15,FILE:0,BULK:0,RULE:Release_Ham,ACTIO N:release,TS:20 X-CID-META: VersionHash:5d391d7,CLOUDID:738965fe-c16b-4159-a099-3b9d0558e447,B ulkID:24020116194210GQBIOB,BulkQuantity:0,Recheck:0,SF:17|19|44|66|38|24|1 02,TC:nil,Content:0,EDM:5,IP:-2,URL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL :0,OSI:0,OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0 X-CID-BVR: 0,NGT X-CID-BAS: 0,NGT,0,_ X-CID-FACTOR: TF_CID_SPAM_FSI,TF_CID_SPAM_SNR,TF_CID_SPAM_FAS,TF_CID_SPAM_FSD X-UUID: 37791ac224ac437d8b6e2347458ab69e-20240201 Received: from mail.kylinos.cn [(39.156.73.10)] by mailgw (envelope-from <chentao@kylinos.cn>) (Generic MTA) with ESMTP id 1346395004; Thu, 01 Feb 2024 16:19:40 +0800 Received: from mail.kylinos.cn (localhost [127.0.0.1]) by mail.kylinos.cn (NSMail) with SMTP id F250CE000EB9; Thu, 1 Feb 2024 16:19:39 +0800 (CST) X-ns-mid: postfix-65BB541B-786294796 Received: from kernel.. (unknown [172.20.15.254]) by mail.kylinos.cn (NSMail) with ESMTPA id 82DABE000EB9; Thu, 1 Feb 2024 16:19:37 +0800 (CST) From: Kunwu Chan <chentao@kylinos.cn> To: chuck.lever@oracle.com, jlayton@kernel.org, neilb@suse.de, kolga@netapp.com, Dai.Ngo@oracle.com, tom@talpey.com Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, Kunwu Chan <chentao@kylinos.cn> Subject: [PATCH] nfsd: Simplify the allocation of slab caches in nfsd_drc_slab_create Date: Thu, 1 Feb 2024 16:19:35 +0800 Message-Id: <20240201081935.200031-1-chentao@kylinos.cn> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789683938819063930 X-GMAIL-MSGID: 1789683938819063930 |
Series |
nfsd: Simplify the allocation of slab caches in nfsd_drc_slab_create
|
|
Commit Message
Kunwu Chan
Feb. 1, 2024, 8:19 a.m. UTC
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
to simplify the creation of SLAB caches.
Make the code cleaner and more readable.
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
---
fs/nfsd/nfscache.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
On 1 Feb 2024, at 3:19, Kunwu Chan wrote: > Use the new KMEM_CACHE() macro instead of direct kmem_cache_create > to simplify the creation of SLAB caches. > Make the code cleaner and more readable. > > Signed-off-by: Kunwu Chan <chentao@kylinos.cn> > --- > fs/nfsd/nfscache.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c > index 5c1a4a0aa605..64ce0cc22197 100644 > --- a/fs/nfsd/nfscache.c > +++ b/fs/nfsd/nfscache.c > @@ -166,8 +166,7 @@ nfsd_reply_cache_free(struct nfsd_drc_bucket *b, struct nfsd_cacherep *rp, > > int nfsd_drc_slab_create(void) > { > - drc_slab = kmem_cache_create("nfsd_drc", > - sizeof(struct nfsd_cacherep), 0, 0, NULL); > + drc_slab = KMEM_CACHE(nfsd_cacherep, 0); > return drc_slab ? 0: -ENOMEM; > } > > -- > 2.39.2 I don't agree that the code is cleaner or more readable like this. I really dislike having to parse through the extra "simplification" to see what's actually being called and sent. Just my .02 worth. Ben
On Fri, 2024-02-02 at 09:13 -0500, Benjamin Coddington wrote: > On 1 Feb 2024, at 3:19, Kunwu Chan wrote: > > > Use the new KMEM_CACHE() macro instead of direct kmem_cache_create > > to simplify the creation of SLAB caches. > > Make the code cleaner and more readable. > > > > Signed-off-by: Kunwu Chan <chentao@kylinos.cn> > > --- > > fs/nfsd/nfscache.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c > > index 5c1a4a0aa605..64ce0cc22197 100644 > > --- a/fs/nfsd/nfscache.c > > +++ b/fs/nfsd/nfscache.c > > @@ -166,8 +166,7 @@ nfsd_reply_cache_free(struct nfsd_drc_bucket *b, struct nfsd_cacherep *rp, > > > > int nfsd_drc_slab_create(void) > > { > > - drc_slab = kmem_cache_create("nfsd_drc", > > - sizeof(struct nfsd_cacherep), 0, 0, NULL); > > + drc_slab = KMEM_CACHE(nfsd_cacherep, 0); > > return drc_slab ? 0: -ENOMEM; > > } > > > > -- > > 2.39.2 > > I don't agree that the code is cleaner or more readable like this. I really > dislike having to parse through the extra "simplification" to see what's > actually being called and sent. > > Just my .02 worth. > > Ben > This will also result in a behavioral change. The "nfsd_drc" string is lost with the above macro and (I think) the new name will be "nfsd_cacherep". I'm not necessarily opposed to that, as I don't think anything depends on the old name, but it should at least be noted in the changelog.
On Sat, 03 Feb 2024, Benjamin Coddington wrote: > On 1 Feb 2024, at 3:19, Kunwu Chan wrote: > > > Use the new KMEM_CACHE() macro instead of direct kmem_cache_create > > to simplify the creation of SLAB caches. > > Make the code cleaner and more readable. > > > > Signed-off-by: Kunwu Chan <chentao@kylinos.cn> > > --- > > fs/nfsd/nfscache.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c > > index 5c1a4a0aa605..64ce0cc22197 100644 > > --- a/fs/nfsd/nfscache.c > > +++ b/fs/nfsd/nfscache.c > > @@ -166,8 +166,7 @@ nfsd_reply_cache_free(struct nfsd_drc_bucket *b, struct nfsd_cacherep *rp, > > > > int nfsd_drc_slab_create(void) > > { > > - drc_slab = kmem_cache_create("nfsd_drc", > > - sizeof(struct nfsd_cacherep), 0, 0, NULL); > > + drc_slab = KMEM_CACHE(nfsd_cacherep, 0); > > return drc_slab ? 0: -ENOMEM; > > } > > > > -- > > 2.39.2 > > I don't agree that the code is cleaner or more readable like this. I really > dislike having to parse through the extra "simplification" to see what's > actually being called and sent. > > Just my .02 worth. > In general I agree that wrappers like this can hinder as much as they help - if not more. In this particular case it doesn't seem to bother me. This is probably because it is only used in initialisation code and I don't look at that nearly as much as code that uses the initialised things. Initialisation/cleanup code often has a lot of boilerplate which can make it look messy. Reducing that, which I think this patch helps with, can be a good thing. So I agree that we should be cautious about using (or creating) new wrapper macros, but in this case I am mildly in favour. Thanks, NeilBrown
Thank you to all the guys who responded to my emails. On 2024/2/2 22:24, Jeff Layton wrote: > On Fri, 2024-02-02 at 09:13 -0500, Benjamin Coddington wrote: >> On 1 Feb 2024, at 3:19, Kunwu Chan wrote: >> >>> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create >>> to simplify the creation of SLAB caches. >>> Make the code cleaner and more readable. >>> >>> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> >>> --- >>> fs/nfsd/nfscache.c | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c >>> index 5c1a4a0aa605..64ce0cc22197 100644 >>> --- a/fs/nfsd/nfscache.c >>> +++ b/fs/nfsd/nfscache.c >>> @@ -166,8 +166,7 @@ nfsd_reply_cache_free(struct nfsd_drc_bucket *b, struct nfsd_cacherep *rp, >>> >>> int nfsd_drc_slab_create(void) >>> { >>> - drc_slab = kmem_cache_create("nfsd_drc", >>> - sizeof(struct nfsd_cacherep), 0, 0, NULL); >>> + drc_slab = KMEM_CACHE(nfsd_cacherep, 0); >>> return drc_slab ? 0: -ENOMEM; >>> } >>> >>> -- >>> 2.39.2 >> >> I don't agree that the code is cleaner or more readable like this. I really >> dislike having to parse through the extra "simplification" to see what's >> actually being called and sent. >> >> Just my .02 worth. >> >> Ben >> > Everyone has a different opinion. From newcomers like me, a simple code is more important than checking all the args of a call function to understand what it does. Too many default arguments can cost us a lot of time that could be spent understanding the main logic of the module code, rather than wasting it on a single line of calls. > This will also result in a behavioral change. The "nfsd_drc" string is > lost with the above macro and (I think) the new name will be > "nfsd_cacherep". I'm not necessarily opposed to that, as I don't think > anything depends on the old name, but it should at least be noted in the > changelog. Thanks i'll update my v2 patch with a new commit msg to show the name change. >
diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c index 5c1a4a0aa605..64ce0cc22197 100644 --- a/fs/nfsd/nfscache.c +++ b/fs/nfsd/nfscache.c @@ -166,8 +166,7 @@ nfsd_reply_cache_free(struct nfsd_drc_bucket *b, struct nfsd_cacherep *rp, int nfsd_drc_slab_create(void) { - drc_slab = kmem_cache_create("nfsd_drc", - sizeof(struct nfsd_cacherep), 0, 0, NULL); + drc_slab = KMEM_CACHE(nfsd_cacherep, 0); return drc_slab ? 0: -ENOMEM; }