On Wed, 6 Feb 2019, Matthew Wilcox wrote: > > > > Coming in late here too but isnt the only DAX case that we are concerned > > about where there was an mmap with the O_DAX option to do direct write > > There is no O_DAX option. There's mount -o dax, but there's nothing that > a program does to say "Use DAX". Hmmm... I thought that a file handle must have a special open mode to actually to a dax map. Looks like that is not the case. > > though? If we only allow this use case then we may not have to worry about > > long term GUP because DAX mapped files will stay in the physical location > > regardless. > > ... except for truncate. And now that I think about it, there was a > desire to support hot-unplug which also needed revoke. Well but that requires that the application unmaps the file. > > Maybe we can solve the long term GUP problem through the requirement that > > user space acquires some sort of means to pin the pages? In the DAX case > > this is given by the filesystem and the hardware will basically take care > > of writeback. > > It's not given by the filesystem. DAX provides a mapping to physical persistent memory that does not go away. Or its a block device. > > > In case of anonymous memory this can be guaranteed otherwise and is less > > critical since these pages are not part of the pagecache and are not > > subject to writeback. > > but are subject to being swapped out? Well that is controlled by mlock and could also involve other means like disabling swap.
