[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1405300849190.8240@gentwo.org>
Date: Fri, 30 May 2014 08:50:56 -0500 (CDT)
From: Christoph Lameter <cl@...two.org>
To: David Rientjes <rientjes@...gle.com>
cc: Marcelo Tosatti <mtosatti@...hat.com>,
Li Zefan <lizefan@...wei.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Lai Jiangshan <laijs@...fujitsu.com>,
Mel Gorman <mgorman@...e.de>, Tejun Heo <tj@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH] page_alloc: skip cpuset enforcement for lower zone
allocations (v5)
On Thu, 29 May 2014, David Rientjes wrote:
> When I said that my point about mempolicies needs more thought, I wasn't
> expecting that there would be no discussion -- at least _something_ that
> would say why we don't care about the mempolicy case.
Lets get Andi involved here too.
> The motivation here is identical for both cpusets and mempolicies. What
> is the significant difference between attaching a process to a cpuset
> without access to lowmem and a process doing set_mempolicy(MPOL_BIND)
> without access to lowmem? Is it because the process should know what it's
> doing if it asks for a mempolicy that doesn't include lowmem? If so, is
> the cpusets case different because the cpuset attacher isn't held to the
> same standard?
>
> I'd argue that an application may never know if it needs to allocate
> GFP_DMA32 or not since its a property of the hardware that its running on
> and my driver may need to access lowmem while yours may not. I may even
> configure CONFIG_ZONE_DMA=n and CONFIG_ZONE_DMA32=n because I know the
> _hardware_ requirements of my platforms.
Right. This is a hardware issue and the hardware is pretty messed up. And
now one wants to use NUMA features?
> If there is no difference, then why are we allowing the exception for
> cpusets and not mempolicies?
>
> I really think you want to allow both cpusets and mempolicies. I'd like
> to hear Christoph's thoughts on it as well, though.
I said something elsewhere in the thread.
--
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