From: David Rientjes <rientjes@google.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Fengguang Wu <fengguang.wu@intel.com>,
David Cohen <david.a.cohen@linux.intel.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Damien Ramonda <damien.ramonda@intel.com>,
Jan Kara <jack@suse.cz>, Linus <torvalds@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Date: Fri, 7 Feb 2014 12:41:38 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.02.1402071239301.4212@chino.kir.corp.google.com> (raw)
In-Reply-To: <52F4B8A4.70405@linux.vnet.ibm.com>
On Fri, 7 Feb 2014, Raghavendra K T wrote:
> So following discussion TODO for my patch is:
>
> 1) Update the changelog with user visible impact of the patch.
> (Andrew's suggestion)
> 2) Add ACCESS_ONCE to numa_node_id().
> 3) Change the "readahead into remote memory" part of the documentation
> which is misleading.
>
> ( I feel no need to add numa_mem_id() since we would specifically limit
> the readahead with MAX_REMOTE_READAHEAD in memoryless cpu cases).
>
I don't understand what you're saying, numa_mem_id() is local memory to
current's cpu. When a node consists only of cpus and not memory it is not
true that all memory is then considered remote, you won't find that in any
specification that defines memory affinity including the ACPI spec. I can
trivially define all cpus on my system to be on memoryless nodes and
having that affect readahead behavior when, in fact, there is affinity
would be ridiculous.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-02-07 20:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 10:53 Raghavendra K T
2014-02-03 8:30 ` Raghavendra K T
2014-02-06 22:51 ` Andrew Morton
2014-02-06 22:58 ` David Rientjes
2014-02-06 23:22 ` Andrew Morton
2014-02-06 23:48 ` David Rientjes
2014-02-06 23:58 ` David Rientjes
2014-02-07 10:42 ` Raghavendra K T
2014-02-07 20:41 ` David Rientjes [this message]
2014-02-10 8:21 ` Raghavendra K T
2014-02-10 10:05 ` David Rientjes
2014-02-10 12:25 ` Raghavendra K T
2014-02-10 21:35 ` David Rientjes
2014-02-13 7:07 ` Raghavendra K T
2014-02-13 8:05 ` David Rientjes
2014-02-13 10:04 ` Raghavendra K T
2014-02-13 22:41 ` David Rientjes
2014-02-14 0:14 ` Nishanth Aravamudan
2014-02-14 0:37 ` Linus Torvalds
2014-02-14 0:45 ` Andrew Morton
2014-02-14 4:32 ` Nishanth Aravamudan
2014-02-14 10:54 ` David Rientjes
2014-02-17 19:28 ` Nishanth Aravamudan
2014-02-17 23:14 ` David Rientjes
2014-02-18 1:31 ` Nishanth Aravamudan
2014-02-17 22:59 ` Linus Torvalds
2014-02-14 7:43 ` Jan Kara
2014-02-17 22:57 ` Linus Torvalds
2014-02-14 5:47 ` Nishanth Aravamudan
2014-02-13 21:06 ` Andrew Morton
2014-02-13 21:42 ` Nishanth Aravamudan
2014-02-10 8:29 ` [RFC PATCH V5 RESEND] " Raghavendra K T
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.02.1402071239301.4212@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=damien.ramonda@intel.com \
--cc=david.a.cohen@linux.intel.com \
--cc=fengguang.wu@intel.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=raghavendra.kt@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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