On 15/08/17 12:06, Boaz Harrosh wrote: > On 14/08/17 19:03, Dan Williams wrote: >> On Mon, Aug 14, 2017 at 7:04 AM, Boaz Harrosh <boazh@xxxxxxxxxx> wrote: >>> >>> Thank you Jan, I'm patiently waiting for this MAP_SYNC flag since I asked for >>> it in 2014. I'm so glad its time is finally do. >>> > > <> > >>> 4] Once we have this flag. And properly implemented at least in one FS >>> and optionally in /dev/pmemX we no longer have any justification for >>> /dev/daxX and it can die a slow and happy death. >> >> I'm all for replacing /dev/dax with filesystem equivalent >> functionality, but I don't think MAP_SYNC gets us fully there. That's >> what the MAP_DIRECT proposal [1] is meant to address. >> > > OK This is true. Could you please summarise for us the exact semantics of both > proposed flags? > > That said I think the big difference is the movability of physical blocks > underneath the mmap mapping. Now for swap files that is a problem. because > of the deadlocks that can happen with memory needed if blocks start moving. > But for an application like nvml? why does it care. Why can't an nvml image file > not be cloned and COWed underneath the NVM application transparently. > OK Sorry didn't do my homework. Struck this out, it is all about RDMA and friends from an "immutable" file. I'll go dig into this now. Thanks Boaz > Sorry for being slow but I don't see why you need MAP_DIRECT from user-mode > If you have MAP_SYNC. Please advise > > (not that the immutable patchset is not a very needed fixing) > >> [1]: https://lkml.org/lkml/2017/8/13/160 >> > > Thanks > Boaz > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
