[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1402071239301.4212@chino.kir.corp.google.com>
Date: Fri, 7 Feb 2014 12:41:38 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Fengguang Wu <fengguang.wu@...el.com>,
David Cohen <david.a.cohen@...ux.intel.com>,
Al Viro <viro@...iv.linux.org.uk>,
Damien Ramonda <damien.ramonda@...el.com>,
Jan Kara <jack@...e.cz>, Linus <torvalds@...ux-foundation.org>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local
memory and limit readahead pages
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 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/
Powered by blists - more mailing lists