Date: Mon, 27 Apr 2015 11:17:43 -0500 (CDT)
From: Christoph Lameter <cl@linux.com>
To: Jerome Glisse <j.glisse@gmail.com>
cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org, jglisse@redhat.com,
        mgorman@suse.de, aarcange@redhat.com, riel@redhat.com,
        airlied@redhat.com, aneesh.kumar@linux.vnet.ibm.com,
        Cameron Buschardt <cabuschardt@nvidia.com>,
        Mark Hairgrove <mhairgrove@nvidia.com>,
        Geoffrey Gerfin <ggerfin@nvidia.com>,
        John McKenna <jmckenna@nvidia.com>, akpm@linux-foundation.org
Subject: Re: Interacting with coherent memory on external devices
In-Reply-To: <20150427154728.GA26980@gmail.com>
Message-ID: <alpine.DEB.2.11.1504271113480.29515@gentwo.org>
References: <20150424150829.GA3840@gmail.com> <alpine.DEB.2.11.1504241052240.9889@gentwo.org> <20150424164325.GD3840@gmail.com> <alpine.DEB.2.11.1504241148420.10475@gentwo.org> <20150424171957.GE3840@gmail.com> <alpine.DEB.2.11.1504241353280.11285@gentwo.org>
 <20150424192859.GF3840@gmail.com> <alpine.DEB.2.11.1504241446560.11700@gentwo.org> <20150425114633.GI5561@linux.vnet.ibm.com> <alpine.DEB.2.11.1504271004240.28895@gentwo.org> <20150427154728.GA26980@gmail.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1591
Lines: 29

On Mon, 27 Apr 2015, Jerome Glisse wrote:

> > Improvements to the general code would be preferred instead of
> > having specialized solutions for a particular hardware alone.  If the
> > general code can then handle the special coprocessor situation then we
> > avoid a lot of code development.
>
> I think Paul only big change would be the memory ZONE changes. Having a
> way to add the device memory as struct page while blocking the kernel
> allocation from using this memory. Beside that i think the autonuma changes
> he would need would really be specific to his usecase but would still
> reuse all of the low level logic.

Well lets avoid that. Access to device memory comparable to what the
drivers do today by establishing page table mappings or a generalization
of DAX approaches would be the most straightforward way of implementing it
and would build based on existing functionality. Page migration currently
does not work with driver mappings or DAX because there is no struct page
that would allow the lockdown of the page. That may require either
continued work on the DAX with page structs approach or new developments
in the page migration logic comparable to the get_user_page() alternative
of simply creating a scatter gather table to just submit a couple of
memory ranges to the I/O subsystem thereby avoiding page structs.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/