Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag

[Boaz Harrosh <boaz@plexistor.com>]

On 02/21/2016 10:57 PM, Dan Williams wrote:
> On Sun, Feb 21, 2016 at 12:24 PM, Boaz Harrosh <boaz@plexistor.com> 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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>