From: Chengming Zhou <[email protected]>
The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove
its usage so we can delete it from slab. No functional change.
Signed-off-by: Chengming Zhou <[email protected]>
---
fs/ocfs2/dlmfs/dlmfs.c | 2 +-
fs/ocfs2/super.c | 7 +++----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/ocfs2/dlmfs/dlmfs.c b/fs/ocfs2/dlmfs/dlmfs.c
index 85215162c9dd..7fc0e920eda7 100644
--- a/fs/ocfs2/dlmfs/dlmfs.c
+++ b/fs/ocfs2/dlmfs/dlmfs.c
@@ -578,7 +578,7 @@ static int __init init_dlmfs_fs(void)
dlmfs_inode_cache = kmem_cache_create("dlmfs_inode_cache",
sizeof(struct dlmfs_inode_private),
0, (SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT|
- SLAB_MEM_SPREAD|SLAB_ACCOUNT),
+ SLAB_ACCOUNT),
dlmfs_init_once);
if (!dlmfs_inode_cache) {
status = -ENOMEM;
diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
index 014c22c4d9d9..8aabaed2c1cb 100644
--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -1706,18 +1706,17 @@ static int ocfs2_initialize_mem_caches(void)
sizeof(struct ocfs2_inode_info),
0,
(SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT|
- SLAB_MEM_SPREAD|SLAB_ACCOUNT),
+ SLAB_ACCOUNT),
ocfs2_inode_init_once);
ocfs2_dquot_cachep = kmem_cache_create("ocfs2_dquot_cache",
sizeof(struct ocfs2_dquot),
0,
- (SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT|
- SLAB_MEM_SPREAD),
+ SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT,
NULL);
ocfs2_qf_chunk_cachep = kmem_cache_create("ocfs2_qf_chunk_cache",
sizeof(struct ocfs2_quota_chunk),
0,
- (SLAB_RECLAIM_ACCOUNT|SLAB_MEM_SPREAD),
+ SLAB_RECLAIM_ACCOUNT,
NULL);
if (!ocfs2_inode_cachep || !ocfs2_dquot_cachep ||
!ocfs2_qf_chunk_cachep) {
--
2.40.1
On 2/24/24 9:50 PM, [email protected] wrote:
> From: Chengming Zhou <[email protected]>
>
> The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove
> its usage so we can delete it from slab. No functional change.
>
If I understand correctly, you are referring the following patch:
https://lore.kernel.org/all/[email protected]/
But it seems that the above patch is not included in mainline yet.
Or am I missing something?
Joseph
On 2024/2/25 20:20, Joseph Qi wrote:
>
>
> On 2/24/24 9:50 PM, [email protected] wrote:
>> From: Chengming Zhou <[email protected]>
>>
>> The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove
>> its usage so we can delete it from slab. No functional change.
>>
> If I understand correctly, you are referring the following patch:
> https://lore.kernel.org/all/[email protected]/
>
> But it seems that the above patch is not included in mainline yet.
> Or am I missing something?
I realize my commit message should explain more why it's a no-op, my bad.
The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
removed so it became a dead flag as of v6.8-rc1. That series[1]
mark it obsolete to avoid confusion for users. So here we can just
remove all its users, which has no functional changes.
[1] https://lore.kernel.org/all/[email protected]/
Thanks!
>
> Joseph
>
On 2/25/24 9:02 PM, Chengming Zhou wrote:
> On 2024/2/25 20:20, Joseph Qi wrote:
>>
>>
>> On 2/24/24 9:50 PM, [email protected] wrote:
>>> From: Chengming Zhou <[email protected]>
>>>
>>> The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove
>>> its usage so we can delete it from slab. No functional change.
>>>
>> If I understand correctly, you are referring the following patch:
>> https://lore.kernel.org/all/[email protected]/
>>
>> But it seems that the above patch is not included in mainline yet.
>> Or am I missing something?
>
> I realize my commit message should explain more why it's a no-op, my bad.
>
> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
> removed so it became a dead flag as of v6.8-rc1. That series[1]
> mark it obsolete to avoid confusion for users. So here we can just
> remove all its users, which has no functional changes.
>
> [1] https://lore.kernel.org/all/[email protected]/
>
Take more look at v6.8-rc1, I've found the following commit:
16a1d968358a ("mm/slab: remove mm/slab.c and slab_def.h")
It seems that after this commit, there is no user of 'SLAB_MEM_SPREAD'. So,
Acked-by: Joseph Qi <[email protected]>