On Sun, Feb 21, 2016 at 12:24 PM, Boaz Harrosh <boaz(a)plexistor.com> wrote:
On 02/21/2016 09:51 PM, Dan Williams wrote:
>> Please advise?
> When this came up a couple weeks ago , 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
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.
> 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 , 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
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?