On Wed, 2015-04-22 at 12:14 -0500, Christoph Lameter wrote: > > > Bottom line is we want today anonymous, share or file mapped memory > > to stay the only kind of memory that exist and we want to choose the > > backing store of each of those kind for better placement depending > > on how memory is use (again which can be in the total control of > > the application). But we do not want to introduce a third kind of > > disjoint memory to userspace, this is today situation and we want > > to move forward to tomorrow solution. > > Frankly, I do not see any benefit here, nor a use case and I wonder who > would adopt this. The future requires higher performance and not more band > aid. You may not but we have a large number of customers who do. In fact I'm quite surprised, what we want to achieve is the most natural way from an application perspective. You have something in memory, whether you got it via malloc, mmap'ing a file, shmem with some other application, ... and you want to work on it with the co-processor that is residing in your address space. Even better, pass a pointer to it to some library you don't control which might itself want to use the coprocessor .... What you propose can simply not provide that natural usage model with any efficiency. It might not be *your* model based on *your* application but that doesn't mean it's not there, and isn't relevant. Ben. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>