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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
