From: David Rientjes <rientjes@google.com>
To: Namjae Jeon <linkinjeon@gmail.com>
Cc: tytso@mit.edu, linux-kernel@vger.kernel.org,
linux-ext4@vger.kernel.org,
Amit Sahrawat <amit.sahrawat83@gmail.com>
Subject: Re: [PATCH] ext4: group info caches set to SLAB_MEM_SPREAD flags.
Date: Sat, 19 Nov 2011 15:29:34 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1111191524200.5986@chino.kir.corp.google.com> (raw)
In-Reply-To: <1321742924-3189-1-git-send-email-linkinjeon@gmail.com>
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.
next prev parent reply other threads:[~2011-11-19 23:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-19 22:48 [PATCH] ext4: group info caches set to SLAB_MEM_SPREAD flags Namjae Jeon
2011-11-19 23:29 ` David Rientjes [this message]
2011-11-20 3:35 ` Ted Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1111191524200.5986@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=amit.sahrawat83@gmail.com \
--cc=linkinjeon@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox