From: Theodore Tso <tytso@MIT.EDU>
To: Amit Sahrawat <amit.sahrawat83@gmail.com>
Cc: Theodore Tso <tytso@mit.edu>,
David Rientjes <rientjes@google.com>,
Namjae Jeon <linkinjeon@gmail.com>,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: slab caches set to SLAB_MEM_SPREAD flags.
Date: Sat, 19 Nov 2011 16:06:58 -0500 [thread overview]
Message-ID: <710B9EAE-A4C8-4E8F-9AA1-F6CBDC84FD54@mit.edu> (raw)
In-Reply-To: <CADDb1s1pLddZ4TQciL=yO-17WwQDyLmzP1E8U0UsyiQqez8Q8A@mail.gmail.com>
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.
Best regards,
-- Ted
next prev parent reply other threads:[~2011-11-19 21:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 15:04 [PATCH] ext4: slab caches set to SLAB_MEM_SPREAD flags Namjae Jeon
2011-11-16 15:51 ` Theodore Tso
2011-11-16 21:52 ` David Rientjes
2011-11-17 5:11 ` Amit Sahrawat
2011-11-17 5:35 ` NamJae Jeon
2011-11-17 15:11 ` Theodore Tso
2011-11-17 21:34 ` Theodore Tso
2011-11-19 13:52 ` NamJae Jeon
2011-11-19 14:42 ` Theodore Tso
2011-11-19 15:40 ` NamJae Jeon
2011-11-19 21:14 ` Theodore Tso
2011-11-19 22:22 ` NamJae Jeon
2011-11-19 21:06 ` Theodore Tso [this message]
2011-11-19 22:16 ` NamJae Jeon
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=710B9EAE-A4C8-4E8F-9AA1-F6CBDC84FD54@mit.edu \
--to=tytso@mit.edu \
--cc=amit.sahrawat83@gmail.com \
--cc=linkinjeon@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.com \
/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