2024-02-29 08:34:47

by Kunwu Chan

[permalink] [raw]
Subject: [PATCH] xfs: use KMEM_CACHE() to create xfs_defer_pending cache

From: Kunwu Chan <[email protected]>

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 <[email protected]>
---
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



2024-02-29 16:20:13

by Darrick J. Wong

[permalink] [raw]
Subject: Re: [PATCH] xfs: use KMEM_CACHE() to create xfs_defer_pending cache

On Thu, Feb 29, 2024 at 04:33:42PM +0800, [email protected] wrote:
> From: Kunwu Chan <[email protected]>
>
> 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 <[email protected]>

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
>
>

2024-02-29 23:26:57

by Dave Chinner

[permalink] [raw]
Subject: Re: [PATCH] xfs: use KMEM_CACHE() to create xfs_defer_pending cache

On Thu, Feb 29, 2024 at 04:33:42PM +0800, [email protected] wrote:
> From: Kunwu Chan <[email protected]>
>
> 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 <[email protected]>
> ---
> 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.
--
Dave Chinner
[email protected]

2024-03-01 02:03:17

by Kunwu Chan

[permalink] [raw]
Subject: Re: [PATCH] xfs: use KMEM_CACHE() to create xfs_defer_pending cache

On 2024/3/1 07:26, Dave Chinner wrote:
> On Thu, Feb 29, 2024 at 04:33:42PM +0800, [email protected] wrote:
>> From: Kunwu Chan <[email protected]>
>>
>> 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 <[email protected]>
>> ---
>> 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.
--
Thanks,
Kunwu