linux-kernel - Re: [PATCH] ext4: group info 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]

Date:	Sat, 19 Nov 2011 15:29:34 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Namjae Jeon <linkinjeon@...il.com>
cc:	tytso@....edu, linux-kernel@...r.kernel.org,
	linux-ext4@...r.kernel.org,
	Amit Sahrawat <amit.sahrawat83@...il.com>
Subject: Re: [PATCH] ext4: group info caches set to SLAB_MEM_SPREAD flags.

On Sun, 20 Nov 2011, Namjae Jeon wrote:

> If group info caches set to SLAB_MEM_SPREAD flags, the allocation is 
> spread evenly over all the memory nodes when using cpuset.

Incorrect, it also requires the cpuset to enable cpuset.memory_spread_slab 
which is not the default.

> It is useful because group info caches are long lived.
> 

As mentioned earlier, you should be able to get performance data as a 
result of this change by using any kernel, enabling CONFIG_CPUSETS and 
CONFIG_SLAB, mounting cpusets at runtime, enabling 
cpuset.memory_spread_slab, creating a mempolicy of MPOL_INTERLEAVE over 
all nodes, and then running your comparison benchmark.  This requires no 
modification of the kernel and will determine what performance benefit 
there is by doing this on your own hardware that you're interested in.

If there is convincing data that suggests it's helpful on your hardware, 
then it would make a good case to merge your patch so users don't need to 
set their own mempolicies that do this.  They'll just need to mount 
cpusets and enable cpuset.memory_spread_slab.

Absent that, there's no purpose in adding this flag.  If you're doing it 
just because it's done in other filesystems, mention that in the changelog 
so it can be judged on that criteria rather than pretending like the NUMA 
affinity actually means anything to your environment.
--
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/