| Message ID | 20240229083342.1128686-1-kunwu.chan@linux.dev (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | xfs: use KMEM_CACHE() to create xfs_defer_pending cache | expand |
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; }