[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1504221020160.24979@gentwo.org>
Date: Wed, 22 Apr 2015 10:25:37 -0500 (CDT)
From: Christoph Lameter <cl@...ux.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc: paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, jglisse@...hat.com, mgorman@...e.de,
aarcange@...hat.com, riel@...hat.com, airlied@...hat.com,
aneesh.kumar@...ux.vnet.ibm.com,
Cameron Buschardt <cabuschardt@...dia.com>,
Mark Hairgrove <mhairgrove@...dia.com>,
Geoffrey Gerfin <ggerfin@...dia.com>,
John McKenna <jmckenna@...dia.com>, akpm@...ux-foundation.org
Subject: Re: Interacting with coherent memory on external devices
On Wed, 22 Apr 2015, Benjamin Herrenschmidt wrote:
> Right, it doesn't look at all like what we want.
Its definitely a way to map memory that is outside of the kernel managed
pool into a user space process. For that matter any device driver could be
doing this as well. The point is that we already have pletora of features
to do this. Putting new requirements on the already
warped-and-screwed-up-beyond-all-hope zombie of a page allocator that we
have today is not the way to do this. In particular what I have head
repeatedly is that we do not want kernel structures alllocated there but
then we still want to use this because we want malloc support in
libraries. The memory has different performance characteristics (for
starters there may be lots of other isssues depending on the device) so we
just add a NUMA "node" with estremely high distance.
There are hooks in glibc where you can replace the memory
management of the apps if you want that.
--
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