On Tue, 2017-05-16 at 09:43 +0100, Mel Gorman wrote: > I'm not sure what you're asking here. migration is only partially > transparent but a move_pages call will be necessary to force pages onto > CDM if binding policies are not used so the cost of migration will be > invisible. Even if you made it "transparent", the migration cost would > be incurred at fault time. If anything, using move_pages would be more > predictable as you control when the cost is incurred. One of the main point of this whole exercise is for applications to not have to bother with any of this and now you are bringing all back into their lap. The base idea behind the counters we have on the link is for the HW to know when memory is accessed "remotely", so that the device driver can make decision about migrating pages into or away from the device, especially so that applications don't have to concern themselves with memory placement. This is also to a certain extent the programming model provided by HMM for non-coherent devices. While some customers want the last % of performance and will explicitly place their memory, the general case out there is to have "plug in" libraries using GPU to accelerate common computational problems behind the scene with no awareness of memory placement. Explicit memory placement becomes unmanageable is heavily shared environment too. Thus we want to reply on the GPU driver moving the pages around where most appropriate (where they are being accessed, either core memory or GPU memory) based on inputs from the HW counters monitoring the link. Cheers, 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>
