public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@MIT.EDU>
To: NamJae Jeon <linkinjeon@gmail.com>
Cc: Theodore Tso <tytso@mit.edu>,
	David Rientjes <rientjes@google.com>,
	linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
	Amit Sahrawat <amit.sahrawat83@gmail.com>
Subject: Re: [PATCH] ext4: slab caches set to SLAB_MEM_SPREAD flags.
Date: Sat, 19 Nov 2011 09:42:00 -0500	[thread overview]
Message-ID: <0912364C-C313-4BCA-9EE2-73F55FE012E6@mit.edu> (raw)
In-Reply-To: <CAKYAXd99NrOC77=p31nax223UOxOONv3_JcLXUpXign8=58Vxw@mail.gmail.com>


On Nov 19, 2011, at 8:52 AM, NamJae Jeon wrote:

> 2011/11/18 Theodore Tso <tytso@mit.edu>:
>> 
>> On Nov 17, 2011, at 10:11 AM, Theodore Tso wrote:
>>> 
>>> So accessing non-local memory can be a really, really big deal.  And this
>>> isn't just theoretical, but have you considered what might happen on a 8
>>> core AMD machine?
>> 
>> Sorry, typo.  This should have read, "have you considered what might happen on a 8 _socket_ AMD machine"?
>> 
> You're right. but..
> It is only useful using cpuset, And have you read cpuset spread
> history link of Amit provided ?
> And why have you still used spread flags for inode cache ?

The inode cache is different for the following reasons:

(1) The memory allocations are long-lived, and there is a good chance for many of them that they will be used by other CPU's on different NUMA nodes.

(2)  There are a very large number of inodes, so uneven allocation of the inodes has a significantly larger impact.

In contrast, the page_io and mballoc allocations are very short lived, there aren't a whole lot of them (check /proc/slabinfo), and they are guaranteed to be used during their very short lifetime on the local CPU node.   So the benefits of spreading them around are not that great, since they aren't that many of them, and downsides of potential 2x or 3x time to access memory is large. 

-- Ted


  reply	other threads:[~2011-11-19 14:42 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 [this message]
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
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=0912364C-C313-4BCA-9EE2-73F55FE012E6@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