On Mon, 27 Apr 2015, Jerome Glisse wrote: > > is the mechanism that DAX relies on in the VM. > > Which would require fare more changes than you seem to think. First using > MIXED|PFNMAP means we loose any kind of memory accounting and forget about > memcg too. Seconds it means we would need to set those flags on all vma, > which kind of point out that something must be wrong here. You will also > need to have vm_ops for all those vma (including for anonymous private vma > which sounds like it will break quite few place that test for that). Then > you have to think about vma that already have vm_ops but you would need > to override it to handle case where its device memory and then forward > other case to the existing vm_ops, extra layering, extra complexity. These vmas would only be used for those section of memory that use memory in the coprocessor. Special memory accounting etc can be done at the device driver layer. Multiple processes would be able to use different GPU contexts (or devices) which provides proper isolations. memcg is about accouting for regular memory and this is not regular memory. It ooks like one would need a lot of special casing in the VM if one wanted to handle f.e. GPU memory as regular memory under Linux. > I think at this point there is nothing more to discuss here. It is pretty > clear to me that any solution using block device/MIXEDMAP would be far > more complex and far more intrusive. I do not mind being prove wrong but > i will certainly not waste my time trying to implement such solution. The device driver method is the current solution used by the GPUS and that would be the natural starting point for development. And they do not currently add code to the core vm. I think we first need to figure out if we cannot do what you want through that method. -- 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>