Message ID | 20240131061924.130083-1-chentao@kylinos.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-45811-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp1701369dyb; Tue, 30 Jan 2024 22:20:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IF/w+8f684XBde3HuGbdxdV8YK39xSwvd2TkgQYnonLxa0lgboRi1utIM9ouCgPaubnIa6F X-Received: by 2002:a17:906:f9c9:b0:a23:32bd:d166 with SMTP id lj9-20020a170906f9c900b00a2332bdd166mr379828ejb.48.1706682011909; Tue, 30 Jan 2024 22:20:11 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706682011; cv=pass; d=google.com; s=arc-20160816; b=aWAH0cFtFsFYXKbedidbJ4WGa2D8gRf9u+L0bcbBPnMZyjMhtS/DNBc9bZL5FZSlOP eJ6HHNGxWkH+qWGf96OyIUTUYjYqBfcgBpzrVr7cncqwqALu6zjShycdP4+zJb8iKlpZ gBzWLFfvOgWPN/O+W067gOiaL/0Vw4/47ONfTD+rnDf5w9EBhHSk3D4rBxUgHBONoVIZ JKMrhi2M94jY1dGt2wJ+OYugq2TN3Q2Yhmh3x4nwiy6p8EqBiFHJoXRO251/IOFYJRZ6 R6SZ3E5c/YnAGDLsDaTrqyaWPLMN8fv6+/IS3VwQC4spRyY5KI7OGVSmlRjY2ZmkAzh7 untw== 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=K3IWfz5AH8x03caSEVWr/sgabCThl3Wiz9XVQlhFoxw=; fh=M9ho/XhliR4utiS3cFlFjMuX+qOTD9S56mmEg70mwSU=; b=wJkeRhR8KOzxt78QenC4rztS77IsXiFlKsDM022MRJng9hJKvdpqKFWiYc7I8GSe9Q 2aOM7BzBX0xNiLU23KqIgnXTh9aMPrbrsT3Tqtw4KN2sNtQduhCRjaP46uuZAKpBPuQW sV19kaIg36Q0HAq4Vitq6CKUVXX7ESYFu3wG/3FPjRoiGB3yAIX9wvB+HV5mNM9GxzEb hGN+OXZLoMHXPsz0txBemu0JjYU2ZeE7HI9kmnJSali938cz5omkHLW8XVQo8KqYLED3 t4x2b2VoZKdSY7B2of+fMvN0Y5BEC/2PHFFElAB8HQOSjI3eTofd0i7Bla00bnXC2dDP C+xA==; 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-45811-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45811-ouuuleilei=gmail.com@vger.kernel.org" X-Forwarded-Encrypted: i=1; AJvYcCWTb8loIFmW3jojmOYFnlEQt6akNpbNB2sOaK4/8fJyyA4PHtg6KscEmvV4kNJqZ1TU0V75Lc6wJR97Mzx9kfQKn3e7qA== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id h6-20020a1709063b4600b00a3553e8e096si3904311ejf.435.2024.01.30.22.20.11 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 22:20:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-45811-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=kylinos.cn); spf=pass (google.com: domain of linux-kernel+bounces-45811-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45811-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 am.mirrors.kernel.org (Postfix) with ESMTPS id 83C841F285A6 for <ouuuleilei@gmail.com>; Wed, 31 Jan 2024 06:20:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 235203EA8D; Wed, 31 Jan 2024 06:19:53 +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 D0D7A3D0A8; Wed, 31 Jan 2024 06:19:37 +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=1706681991; cv=none; b=aEehZOQYykqSseToVkyG1iJ0FayY8HOOWc2ZuX8l8dIK4kxMS0ENQdfGft+o47ho7qANqWQzCsxLDAX95FUtSflaawCUj/Kb3JiAzsi2kN6EsZ12Q57Z3q+wpuhs+ESLPnOQg3ugWteIqoUF/w77mngA9WYiQOXKH9vBJb6SqpU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706681991; c=relaxed/simple; bh=u5O3/gNRSdF1Vka2tF/34OTpsuldLvuRZepGrl5h7k0=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=SMd1/Ht+hwPMxiZzVQrytTKDNCCdD+anj/qi/Ds1xW4e3l7v/khJH85HxE1ueXqAzq2V0FYjkpG2QgRqaX4/ufGujJr9Wl5ehxhKWoJbBjQWa2TQJuZE+gXn/WP9zakGgSy9iI4/6Q2MYFtMwXI8rtXceGsQKzKQxvlwSP3gJ7I= 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: 40ea3aee49ee4d33a1f27c107259acbd-20240131 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.35,REQID:c50e72fa-99b4-4905-8d10-937242d3f027,IP:20, URL:0,TC:0,Content:0,EDM:0,RT:0,SF:-15,FILE:0,BULK:0,RULE:Release_Ham,ACTI ON:release,TS:5 X-CID-INFO: VERSION:1.1.35,REQID:c50e72fa-99b4-4905-8d10-937242d3f027,IP:20,UR L:0,TC:0,Content:0,EDM:0,RT:0,SF:-15,FILE:0,BULK:0,RULE:Release_Ham,ACTION :release,TS:5 X-CID-META: VersionHash:5d391d7,CLOUDID:b83cf37f-4f93-4875-95e7-8c66ea833d57,B ulkID:240131141931X8CLJG0B,BulkQuantity:0,Recheck:0,SF:38|24|17|19|44|66|1 02,TC:nil,Content:0,EDM:-3,IP:-2,URL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,CO L: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_SNR,TF_CID_SPAM_FAS,TF_CID_SPAM_FSD,TF_CID_SPAM_FSI X-UUID: 40ea3aee49ee4d33a1f27c107259acbd-20240131 Received: from mail.kylinos.cn [(39.156.73.10)] by mailgw (envelope-from <chentao@kylinos.cn>) (Generic MTA) with ESMTP id 297476359; Wed, 31 Jan 2024 14:19:28 +0800 Received: from mail.kylinos.cn (localhost [127.0.0.1]) by mail.kylinos.cn (NSMail) with SMTP id 3AAC9E000EB9; Wed, 31 Jan 2024 14:19:27 +0800 (CST) X-ns-mid: postfix-65B9E66F-40888197 Received: from kernel.. (unknown [172.20.15.254]) by mail.kylinos.cn (NSMail) with ESMTPA id 74415E000EB9; Wed, 31 Jan 2024 14:19:25 +0800 (CST) From: Kunwu Chan <chentao@kylinos.cn> To: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, Kunwu Chan <chentao@kylinos.cn> Subject: [PATCH] btrfs: Simplify the allocation of slab caches in btrfs_delayed_inode_init Date: Wed, 31 Jan 2024 14:19:24 +0800 Message-Id: <20240131061924.130083-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: 1789585797563387421 X-GMAIL-MSGID: 1789585797563387421 |
Series |
btrfs: Simplify the allocation of slab caches in btrfs_delayed_inode_init
|
|
Commit Message
Kunwu Chan
Jan. 31, 2024, 6:19 a.m. UTC
commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation")
introduces a new macro.
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
to simplify the creation of SLAB caches.
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
---
fs/btrfs/delayed-inode.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
Comments
On 31.01.24 07:20, Kunwu Chan wrote: > commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation") > introduces a new macro. > Use the new KMEM_CACHE() macro instead of direct kmem_cache_create That commit is 17 years old. Why should we switch to it _now_? I wouldn't call it a new macro. Don't get me wrong, I don't oppose the patch, but I'd prefer a better explanation why now and not 17 years ago when the macro got introduced. > to simplify the creation of SLAB caches. > > Signed-off-by: Kunwu Chan <chentao@kylinos.cn> > --- > fs/btrfs/delayed-inode.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c > index 08102883f560..8c748c6cdf6d 100644 > --- a/fs/btrfs/delayed-inode.c > +++ b/fs/btrfs/delayed-inode.c > @@ -28,11 +28,7 @@ static struct kmem_cache *delayed_node_cache; > > int __init btrfs_delayed_inode_init(void) > { > - delayed_node_cache = kmem_cache_create("btrfs_delayed_node", > - sizeof(struct btrfs_delayed_node), > - 0, > - SLAB_MEM_SPREAD, > - NULL); > + delayed_node_cache = KMEM_CACHE(btrfs_delayed_node, SLAB_MEM_SPREAD); > if (!delayed_node_cache) > return -ENOMEM; > return 0;
On Wed, Jan 31, 2024 at 10:20:35AM +0000, Johannes Thumshirn wrote: > On 31.01.24 07:20, Kunwu Chan wrote: > > commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation") > > introduces a new macro. > > Use the new KMEM_CACHE() macro instead of direct kmem_cache_create > > That commit is 17 years old. Why should we switch to it _now_? I > wouldn't call it a new macro. I had the same reaction after checking the commit that added it. > > Don't get me wrong, I don't oppose the patch, but I'd prefer a better > explanation why now and not 17 years ago when the macro got introduced. We can add the macros where possible, at least it hides all the 0 or NULL parameters, but yeah with a better changelog.
On 2024/1/31 18:20, Johannes Thumshirn wrote: > On 31.01.24 07:20, Kunwu Chan wrote: >> commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation") >> introduces a new macro. >> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create > > That commit is 17 years old. Why should we switch to it _now_? I > wouldn't call it a new macro. > > Don't get me wrong, I don't oppose the patch, but I'd prefer a better > explanation why now and not 17 years ago when the macro got introduced. > Thanks for your attention. Like David say in https://lore.kernel.org/all/20240131183929.GP31555@twin.jikos.cz/#t. The main reason is 'it hides all the 0 or NULL parameters', makes the code cleaner and more readable. So i'll update the commit msg to this: 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. And resend a v2 patch. Thanks again. >> to simplify the creation of SLAB caches. >> >> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> >> --- >> fs/btrfs/delayed-inode.c | 6 +----- >> 1 file changed, 1 insertion(+), 5 deletions(-) >> >> diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c >> index 08102883f560..8c748c6cdf6d 100644 >> --- a/fs/btrfs/delayed-inode.c >> +++ b/fs/btrfs/delayed-inode.c >> @@ -28,11 +28,7 @@ static struct kmem_cache *delayed_node_cache; >> >> int __init btrfs_delayed_inode_init(void) >> { >> - delayed_node_cache = kmem_cache_create("btrfs_delayed_node", >> - sizeof(struct btrfs_delayed_node), >> - 0, >> - SLAB_MEM_SPREAD, >> - NULL); >> + delayed_node_cache = KMEM_CACHE(btrfs_delayed_node, SLAB_MEM_SPREAD); >> if (!delayed_node_cache) >> return -ENOMEM; >> return 0; >
… > So i'll update the commit msg to this: > > 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. … * Please replace the word “new” by a reference to the commit 8eb8284b412906181357c2b0110d879d5af95e52 ("usercopy: Prepare for usercopy whitelisting"). See also related background information from 2017-06-10. * How does your response fit to the repetition of improvable change descriptions? Example: [PATCH] btrfs: Simplify the allocation of slab caches in btrfs_transaction_init https://lore.kernel.org/lkml/20240201093554.208092-1-chentao@kylinos.cn/ https://lkml.org/lkml/2024/2/1/387 * How do you think about to group similar source code transformations into patch series? Regards, Markus
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c index 08102883f560..8c748c6cdf6d 100644 --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -28,11 +28,7 @@ static struct kmem_cache *delayed_node_cache; int __init btrfs_delayed_inode_init(void) { - delayed_node_cache = kmem_cache_create("btrfs_delayed_node", - sizeof(struct btrfs_delayed_node), - 0, - SLAB_MEM_SPREAD, - NULL); + delayed_node_cache = KMEM_CACHE(btrfs_delayed_node, SLAB_MEM_SPREAD); if (!delayed_node_cache) return -ENOMEM; return 0;