linux-kernel - Re: [PATCH] ext4: slab caches set to SLAB_MEM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKYAXd85nEpYhiA3VFC53TA4jQJfWixDagab4WRWrsSANyLp-Q@mail.gmail.com>
Date:	Sun, 20 Nov 2011 07:16:51 +0900
From:	NamJae Jeon <linkinjeon@...il.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Amit Sahrawat <amit.sahrawat83@...il.com>,
	David Rientjes <rientjes@...gle.com>,
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: slab caches set to SLAB_MEM_SPREAD flags.

2011/11/20 Theodore Tso <tytso@....edu>:
>
> On Nov 17, 2011, at 12:11 AM, Amit Sahrawat wrote:
>> We looked for the details regarding the introduction of
>> SLAB_MEM_SHARED(http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-02/msg01409.html
>> - provide the slab cache infrastructure to support cpuset memory
>> spreading), and further the changes were introduced across all
>> filesystems - http://lwn.net/Articles/173654/.
>
> The main thing I see when I look at this list was it was focused only on the file system's inode structures, or other structures which were long lived and likely to be accessed from many NUMA nodes other than the one where it was originally allocated.
>
> It's unfortunate that this has gotten turned into a much broader generalization that all slab caches should have this flag set.   Perhaps it might be interesting to reflect on the fact that if it was always good to do this, that a flag wouldn't be used to control this behavior, but rather it would be done conditionally?
>
> It's all very good to send  lots of clean up patches, perhaps as a way to learn how to submit kernel patches.   But I would ask people who do this to understand a bit more deeply what is going on.  What's most important for people who are getting started with kernel development is not so much the mechanics of submitting patches, but understanding why things work the way they do.

Actually I checked btrfs before I posted this patch, I was more
confused by temparal slab caches similar with page_io caches of ext4
were not even using the spread flags in btrfs.
I apologize for lacking a point. I will post a patch after
understanding a bit more deeply.

>
> Best regards,
>
> -- Ted
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/