2024-01-31 06:20:02

by Kunwu Chan

[permalink] [raw]
Subject: [PATCH] btrfs: Simplify the allocation of slab caches in btrfs_delayed_inode_init

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



2024-01-31 10:24:14

by Johannes Thumshirn

[permalink] [raw]
Subject: Re: [PATCH] btrfs: Simplify the allocation of slab caches in btrfs_delayed_inode_init

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

2024-01-31 19:13:09

by David Sterba

[permalink] [raw]
Subject: Re: [PATCH] btrfs: Simplify the allocation of slab caches in btrfs_delayed_inode_init

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.

2024-02-01 08:44:18

by Kunwu Chan

[permalink] [raw]
Subject: Re: [PATCH] btrfs: Simplify the allocation of slab caches in btrfs_delayed_inode_init

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/[email protected]/#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 <[email protected]>
>> ---
>> 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;
>
--
Thanks,
Kunwu


2024-02-01 12:11:00

by Markus Elfring

[permalink] [raw]
Subject: Re: btrfs: Simplify the allocation of slab caches in btrfs_delayed_inode_init


> 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/[email protected]/
https://lkml.org/lkml/2024/2/1/387

* How do you think about to group similar source code transformations
into patch series?


Regards,
Markus