On Tue, Jan 26, 2021 at 01:26:45AM +0000, Song Bao Hua (Barry Song) wrote: > > On Mon, Jan 25, 2021 at 11:35:22PM +0000, Song Bao Hua (Barry Song) wrote: > > > > > > On Mon, Jan 25, 2021 at 10:21:14PM +0000, Song Bao Hua (Barry Song) wrote: > > > > > mlock, while certainly be able to prevent swapping out, it won't > > > > > be able to stop page moving due to: > > > > > * memory compaction in alloc_pages() > > > > > * making huge pages > > > > > * numa balance > > > > > * memory compaction in CMA > > > > > > > > Enabling those things is a major reason to have SVA device in the > > > > first place, providing a SW API to turn it all off seems like the > > > > wrong direction. > > > > > > I wouldn't say this is a major reason to have SVA. If we read the > > > history of SVA and papers, people would think easy programming due > > > to data struct sharing between cpu and device, and process space > > > isolation in device would be the major reasons for SVA. SVA also > > > declares it supports zero-copy while zero-copy doesn't necessarily > > > depend on SVA. > > > > Once you have to explicitly make system calls to declare memory under > > IO, you loose all of that. > > > > Since you've asked the app to be explicit about the DMAs it intends to > > do, there is not really much reason to use SVA for those DMAs anymore. > > Let's see a non-SVA case. We are not using SVA, we can have > a memory pool by hugetlb or pin, and app can allocate memory > from this pool, and get stable I/O performance on the memory > from the pool. But device has its separate page table which > is not bound with this process, thus lacking the protection > of process space isolation. Plus, CPU and device are using > different address. So you are relying on the platform to do the SVA for the device? This feels like it goes back to another topic where I felt the SVA setup uAPI should be shared and not buried into every driver's unique ioctls. Having something like this in a shared SVA system is somewhat less strange. Jason
