On 02/21/2016 10:57 PM, Dan Williams wrote: > On Sun, Feb 21, 2016 at 12:24 PM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: >> On 02/21/2016 09:51 PM, Dan Williams wrote: >> <> >>>> Please advise? >>> >>> When this came up a couple weeks ago [1], the conclusion I came away >>> with is >> >> I think I saw that talk, no this was not suggested. What was suggested >> was an FS / mount knob. That would break semantics, this here does not >> break anything. > > No, it was a MAP_DAX mmap flag, similar to this proposal. The > difference being that MAP_DAX was all or nothing (DAX vs page cache) > to address MAP_SHARED semantics. > Big difference no? I'm not talking about cached access at all. >> >>> that if an application wants to avoid the overhead of DAX >>> semantics it needs to use an alternative to DAX access methods. Maybe >>> a new pmem aware fs like Nova [2], or some other mechanism that >>> bypasses the semantics that existing applications on top of ext4 and >>> xfs expect. >>> >> >> But my suggestion does not break any "existing applications" and does >> not break any semantics of ext4 or xfs. (That I can see) >> >> As I said above it perfectly co exists with existing applications and >> is the best of both worlds. The both applications can write to the >> same page and will not break any of application's expectation. Old or >> new. >> >> Please point me to where I'm wrong in the code submitted? >> >> Besides even an FS like Nova will need a flag per vma like this, >> it will need to sort out the different type of application. So >> here is how this is communicated, on the mmap call, how else? >> And also works for xfs or ext4 >> >> Do you not see how this is entirely different then what was >> proposed? or am I totally missing something? Again please show >> me how this breaks anything's expectations. >> > > What happens for MAP_SHARED mappings with mixed pmem aware/unaware > applications? Does MAP_PMEM_AWARE also imply awareness of other > applications that may be dirtying cachelines without taking > responsibility for making them persistent? > Sure. please have a look. What happens is that the legacy app will add the page to the radix tree, come the fsync it will be flushed. Even though a "new-type" app might fault on the same page before or after, which did not add it to the radix tree. So yes, all pages faulted by legacy apps will be flushed. I have manually tested all this and it seems to work. Can you see a theoretical scenario where it would not? We are yet to setup our NvDIMM machines to be testing all this with automatic power-off cycles and see who it holds, Hence the RFC status. Thanks Boaz -- 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>