Message ID | 20240229083342.1128686-1-kunwu.chan@linux.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-86296-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2097:b0:108:e6aa:91d0 with SMTP id gs23csp253045dyb; Thu, 29 Feb 2024 00:34:55 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUAhBuSoV1vipf0ypplnZya4+KWVFLTqSgL5RFj0zEKmvZMsxMZKiLfCSM8y/1NuzQuJvMbiJqJUM4cnGliCK/awd4zAA== X-Google-Smtp-Source: AGHT+IHGxKSDXLd2jlFcpvK9UAQJmAGrIl37gwsaX3Cmm89si8kKfXtFwMkevWATElQvnWafSMwc X-Received: by 2002:a50:9e8e:0:b0:566:16e4:b6b3 with SMTP id a14-20020a509e8e000000b0056616e4b6b3mr1032706edf.36.1709195695688; Thu, 29 Feb 2024 00:34:55 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709195695; cv=pass; d=google.com; s=arc-20160816; b=a4BAyBloA1wfZAW+Ss5l6zu3CL3GE23+DDPiHZmzWkAqomzWlTeKm8jTjFK0/kHqW7 Espu30w8IsmXUR3mBa+ZFmngahd0WPjAuZzVewu+7snZpuGq3MKNjaPi+exhK/Q8YPld IHxmyg2PzoYMenu4UxjqegCsbZGyfuDykfGt2ar2lpxsKpxj0P942+PtRlIDXcw4rj2j gO0V9ayy2l/h8AhY0TGVL+A9syyfolvBp2YJZVrzdTG2gZKLgcI+PY55m4ZJSjr1DAnT SEsRCqAYGXRUx7nazz6lgwl0WWroCoe1zGenCSTCzaKHRrsSzf6+yrl4vbcR7zWQ4jCX 8tPg== 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:dkim-signature; bh=c4hqPXVYzAPKLJpLD1lYkRxhseQa0+qO76gLH6MQGf8=; fh=ydGGCJ5dyMuKeCzfl7xE3L4DkU8f6yj4O7KBVMWAACE=; b=UqJYBE2SVe9byj6tq5/vVE762VDGyJ3JGlYSTJkTWB1alXOD0y5W1ooTTQQant3LAA chrQmtMIaNqAGiKaX5b1JFPldYZZjdl9FvmRUwuqG2zBj1pN54cDnp0jWs/g1Wu9dyLI o1Eghjxd/L0b4FtUTNTmKT05e4w0oIRLpsU3ex/OiujHhkmhiZLrHPH+xABYb1p14e+u u74/Q8beGKjVqOdXPbqR+s8+G5wSBZmghQwOSN3JDQJ2v52LYtxjjNpe87VX7truK++2 9UHc17gCaEMMZ2qPzO5Inj8aBPfevFxrz4pY/H0j9z1pF6EL1cIBtQhrpmL2EmVMaHaP wz5w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=mQLRID5R; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-86296-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-86296-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id v19-20020a056402349300b0056621739914si395681edc.79.2024.02.29.00.34.55 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Feb 2024 00:34:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-86296-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; dkim=pass header.i=@linux.dev header.s=key1 header.b=mQLRID5R; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-86296-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-86296-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev 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 4D3BF1F2478E for <ouuuleilei@gmail.com>; Thu, 29 Feb 2024 08:34:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0911950278; Thu, 29 Feb 2024 08:34:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="mQLRID5R" Received: from out-187.mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) (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 D0126481D1 for <linux-kernel@vger.kernel.org>; Thu, 29 Feb 2024 08:34:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.187 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709195680; cv=none; b=g68FyyUt0C5y2kU4rL0lopVQ4XkI6B9bjOa6MsE4bJykKhoTjLSM+KhfFczNLCZhsqrT5rov4iAIrncXMWVy/WQDvyy7Rjy1Omj4Aomxp4uNsQPffrnTe23G/a0zQo5Jhdrh3u6bv3mzLK7oX3IvMTWzaoFePAG1f/hz9hTc+Ug= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709195680; c=relaxed/simple; bh=PtmJDoA1H7SAn1CqzqBzHGTEfAfkzw/1rSUcVqWa4Ig=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=CehP9+YNdYKvxeQT6HENwkmPxf6c2Gnq/P+JDI8W4DXxn/1+/W/RapUkwXCF21zpNSWKSHVJRG/HGzZ8vxoqyePasXNI11qbqQPpvSu0HEZNX+4jTmd+1F2dcLBo4iMH3mjqdpznz++P+ayuuH0nCNa4kjSu+NV0kczfX8ej5k4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=mQLRID5R; arc=none smtp.client-ip=91.218.175.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709195675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=c4hqPXVYzAPKLJpLD1lYkRxhseQa0+qO76gLH6MQGf8=; b=mQLRID5RGJsIYKfmSTAqOY53BAsA4WAZ0BePYmie39/1QizuzOovA5S4I5TBOiAVyoWp3H CNJjh9ZM5cv+BCAsrdYIudxwvCfWG/jGFQcnfH3xj7SVFa3QkHEHr0UFNmJ4+yKZpbndt8 jVp0H/m+WelwzyxcDMbdVU+sfssmHAs= From: kunwu.chan@linux.dev To: chandan.babu@oracle.com, djwong@kernel.org Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, Kunwu Chan <chentao@kylinos.cn> Subject: [PATCH] xfs: use KMEM_CACHE() to create xfs_defer_pending cache Date: Thu, 29 Feb 2024 16:33:42 +0800 Message-Id: <20240229083342.1128686-1-kunwu.chan@linux.dev> 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: 8bit X-Migadu-Flow: FLOW_OUT X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792221586172401969 X-GMAIL-MSGID: 1792221586172401969 |
Series |
xfs: use KMEM_CACHE() to create xfs_defer_pending cache
|
|
Commit Message
kunwu.chan@linux.dev
Feb. 29, 2024, 8:33 a.m. UTC
From: Kunwu Chan <chentao@kylinos.cn> Use the KMEM_CACHE() macro instead of kmem_cache_create() to simplify the creation of SLAB caches when the default values are used. Signed-off-by: Kunwu Chan <chentao@kylinos.cn> --- fs/xfs/libxfs/xfs_defer.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
Comments
On Thu, Feb 29, 2024 at 04:33:42PM +0800, kunwu.chan@linux.dev wrote: > From: Kunwu Chan <chentao@kylinos.cn> > > Use the KMEM_CACHE() macro instead of kmem_cache_create() to simplify > the creation of SLAB caches when the default values are used. > > Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Why bother? The vast majority of the kernel is still using kmem_cache_create(), not the weird, shouty macro that doesn't actually tell us what it is doing with said kmem_cache...... Up until now we've chosen not switch XFS to use it because many of the slab caches we use in XFS are not just "default" slab caches. IOWs, we still have to use kmem_cache_create() for a lot of the caches we create, so we may as well use kmem_cache_create() for all of them rather than have to go look up what KMEM_CACHE() translates to every time we are looking at how slab caches are created. Also, if you are going to change simple API stuff like this in XFS, please do all the conversions in a single patch. It takes much less time and resources to review and merge a single patch compared to a pile of dozen independent one line patches... --D > --- > fs/xfs/libxfs/xfs_defer.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c > index 66a17910d021..6d957fcc17f2 100644 > --- a/fs/xfs/libxfs/xfs_defer.c > +++ b/fs/xfs/libxfs/xfs_defer.c > @@ -1143,9 +1143,7 @@ xfs_defer_resources_rele( > static inline int __init > xfs_defer_init_cache(void) > { > - xfs_defer_pending_cache = kmem_cache_create("xfs_defer_pending", > - sizeof(struct xfs_defer_pending), > - 0, 0, NULL); > + xfs_defer_pending_cache = KMEM_CACHE(xfs_defer_pending, 0); > > return xfs_defer_pending_cache != NULL ? 0 : -ENOMEM; > } > -- > 2.39.2 > >
On Thu, Feb 29, 2024 at 04:33:42PM +0800, kunwu.chan@linux.dev wrote: > From: Kunwu Chan <chentao@kylinos.cn> > > Use the KMEM_CACHE() macro instead of kmem_cache_create() to simplify > the creation of SLAB caches when the default values are used. > > Signed-off-by: Kunwu Chan <chentao@kylinos.cn> > --- > fs/xfs/libxfs/xfs_defer.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c > index 66a17910d021..6d957fcc17f2 100644 > --- a/fs/xfs/libxfs/xfs_defer.c > +++ b/fs/xfs/libxfs/xfs_defer.c > @@ -1143,9 +1143,7 @@ xfs_defer_resources_rele( > static inline int __init > xfs_defer_init_cache(void) > { > - xfs_defer_pending_cache = kmem_cache_create("xfs_defer_pending", > - sizeof(struct xfs_defer_pending), > - 0, 0, NULL); > + xfs_defer_pending_cache = KMEM_CACHE(xfs_defer_pending, 0); > > return xfs_defer_pending_cache != NULL ? 0 : -ENOMEM; > } Please stop wasting our time by trying to make changes that have already been rejected. I gave you good reasons last time for why we aren't going to make this change in XFS, and now you've forced Darrick to waste time repeating all those same reasons. You did not respond to my review comments last time, and now you are posting more patches that make the same rejected change. PLease listen to the feedback you are given. Indeed, please respond and acknowledge that you have read and understood the feedback you have been given, otherwise I'll consider anything from this email address as "just another annoying bot" and killfile it. -Dave.
On 2024/3/1 07:26, Dave Chinner wrote: > On Thu, Feb 29, 2024 at 04:33:42PM +0800, kunwu.chan@linux.dev wrote: >> From: Kunwu Chan <chentao@kylinos.cn> >> >> Use the KMEM_CACHE() macro instead of kmem_cache_create() to simplify >> the creation of SLAB caches when the default values are used. >> >> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> >> --- >> fs/xfs/libxfs/xfs_defer.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c >> index 66a17910d021..6d957fcc17f2 100644 >> --- a/fs/xfs/libxfs/xfs_defer.c >> +++ b/fs/xfs/libxfs/xfs_defer.c >> @@ -1143,9 +1143,7 @@ xfs_defer_resources_rele( >> static inline int __init >> xfs_defer_init_cache(void) >> { >> - xfs_defer_pending_cache = kmem_cache_create("xfs_defer_pending", >> - sizeof(struct xfs_defer_pending), >> - 0, 0, NULL); >> + xfs_defer_pending_cache = KMEM_CACHE(xfs_defer_pending, 0); >> >> return xfs_defer_pending_cache != NULL ? 0 : -ENOMEM; >> } > > Please stop wasting our time by trying to make changes that have > already been rejected. I gave you good reasons last time for why we > aren't going to make this change in XFS, and now you've forced > Darrick to waste time repeating all those same reasons. You did not > respond to my review comments last time, and now you are posting > more patches that make the same rejected change. > Sorry for the bother. It's my bad.That reply email was probably quarantined because of my mailbox server, and I just found it on the quarantine list. I'll stop from doing this. Apologies again for my interruption. > PLease listen to the feedback you are given. Indeed, please respond > and acknowledge that you have read and understood the feedback you > have been given, otherwise I'll consider anything from this email > address as "just another annoying bot" and killfile it. Thank you very much for your detailed reply and explanation, I just saw it, this patch is my problem, I forgot to check the previous mailing list at the time. Sorry again for the bad mood I have caused you. > > -Dave.
diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c index 66a17910d021..6d957fcc17f2 100644 --- a/fs/xfs/libxfs/xfs_defer.c +++ b/fs/xfs/libxfs/xfs_defer.c @@ -1143,9 +1143,7 @@ xfs_defer_resources_rele( static inline int __init xfs_defer_init_cache(void) { - xfs_defer_pending_cache = kmem_cache_create("xfs_defer_pending", - sizeof(struct xfs_defer_pending), - 0, 0, NULL); + xfs_defer_pending_cache = KMEM_CACHE(xfs_defer_pending, 0); return xfs_defer_pending_cache != NULL ? 0 : -ENOMEM; }