New MAP_PMEM_AWARE mmap flag

Hi all

Recent DAX code fixed the cl_flushing ie durability of mmap access of direct persistent-memory from applications. It uses the radix-tree per inode to track the indexes of a file that where page-faulted for write. Then at m/fsync time it would cl_flush these pages and clean the radix-tree, for the next round.

Sigh, that is life, for legacy applications this is the price we must pay. But for NV aware applications like nvml library, we pay extra extra price, even if we do not actually call m/fsync eventually. For these applications these extra resources and especially the extra radix locking per page-fault, costs a lot, like x3 a lot.

What we propose here is a way for those applications to enjoy the boost and still not sacrifice any correctness of legacy applications. Any concurrent access from legacy apps vs nv-aware apps even to the same file / same page, will work correctly.

We do that by defining a new MMAP flag that is set by the nv-aware app. this flag is carried by the VMA. In the dax code we bypass any radix handling of the page if this flag is set. Those pages accessed *without* this flag will be added to the radix-tree, those with will not. At m/fsync time if the radix tree is then empty nothing will happen.

These are very simple none intrusive patches with minimum risk. (I think) They are based on v4.5-rc5. If you need a rebase on any other tree please say.

Please consider this new flag for those of us people who specialize in persistent-memory setups and want to extract any possible mileage out of our systems.

Also attached for reference a 3rd patch to the nvml library to use
the new flag. Which brings me to the issue of persistent_memcpy / persistent_flush. Currently this library is for x86_64 only, using the movnt instructions. The gcc compiler should have a per ARCH facility for durable memory accesses. So applications can be portable across systems.

Please advise?

Quoted 1 line

Please advise?

When this came up a couple weeks ago [1], the conclusion I came away with is

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.

On 02/21/2016 09:51 PM, Dan Williams wrote:
<>

Quoted 4 lines

Quoted 1 line

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.

Quoted 7 lines

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.

Quoted 7 lines · Boaz Harrosh

On 02/21/2016 09:51 PM, Dan Williams wrote:
<>

Quoted 4 lines

Quoted 1 line

Please advise?

When this came up a couple weeks ago [1], the conclusion I came away with is

Quoted 3 lines

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.

Quoted 18 lines

Quoted 7 lines

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?

Quoted 9 lines

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?

Quoted 8 lines · Dan Williams

Quoted 7 lines · Boaz Harrosh

On 02/21/2016 09:51 PM, Dan Williams wrote:
<>

Quoted 4 lines

Quoted 1 line

Please advise?

When this came up a couple weeks ago [1], the conclusion I came away with is

Quoted 8 lines

Quoted 3 lines

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.

Quoted 28 lines

Quoted 18 lines

Quoted 7 lines

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?

Quoted 9 lines

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.

Quoted 5 lines

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?

Quoted 11 lines · Boaz Harrosh

Quoted 2 lines · Dan Williams

Quoted 1 line · Boaz Harrosh

On 02/21/2016 09:51 PM, Dan Williams wrote:

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?

I'm worried about the scenario where the pmem aware app assumes that none of the cachelines in its mapping are dirty when it goes to issue pcommit. We'll have two applications with different perceptions of when writes are durable. Maybe it's not a problem in practice, at least current generation x86 cpus flush existing dirty cachelines when performing non-temporal stores. However, it bothers me that there are cpus where a pmem-unaware app could prevent a pmem-aware app from making writes durable. It seems if one app has established a MAP_PMEM_AWARE mapping it needs guarantees that all apps participating in that shared mapping have the same awareness.

Another potential issue is that MAP_PMEM_AWARE is not enough on its own. If the filesystem or inode does not support DAX the application needs to assume page cache semantics. At a minimum MAP_PMEM_AWARE requests would need to fail if DAX is not available.

Quoted 13 lines · Dan Williams

Quoted 11 lines · Boaz Harrosh

Quoted 2 lines · Dan Williams

Quoted 1 line · Boaz Harrosh

On 02/21/2016 09:51 PM, Dan Williams wrote:

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?

Quoted 10 lines

I'm worried about the scenario where the pmem aware app assumes that none of the cachelines in its mapping are dirty when it goes to issue pcommit. We'll have two applications with different perceptions of when writes are durable. Maybe it's not a problem in practice, at least current generation x86 cpus flush existing dirty cachelines when performing non-temporal stores. However, it bothers me that there are cpus where a pmem-unaware app could prevent a pmem-aware app from making writes durable. It seems if one app has established a MAP_PMEM_AWARE mapping it needs guarantees that all apps participating in that shared mapping have the same awareness.

Which, in practice, cannot work. Think cp, rsync, or any other program a user can run that can read the file the MAP_PMEM_AWARE application is using.

Quoted 4 lines

Another potential issue is that MAP_PMEM_AWARE is not enough on its own. If the filesystem or inode does not support DAX the application needs to assume page cache semantics. At a minimum MAP_PMEM_AWARE requests would need to fail if DAX is not available.

They will always still need to call msync()/fsync() to guarantee data integrity, because the filesystem metadata that indexes the data still needs to be committed before data integrity can be guaranteed. i.e. MAP_PMEM_AWARE by itself it not sufficient for data integrity, and so the app will have to be written like any other app that uses page cache based mmap().

Indeed, the application cannot even assume that a fully allocated file does not require msync/fsync because the filesystem may be doing things like dedupe, defrag, copy on write, etc behind the back of the application and so file metadata changes may still be in volatile RAM even though the application has flushed it's data. Applications have no idea what the underlying filesystem and storage is doing and so they cannot assume that complete data integrity is provided by userspace driven CPU cache flush instructions on their file data.

This "pmem aware applications only need to commit their data" thinking is what got us into this mess in the first place. It's wrong, and we need to stop trying to make pmem work this way because it's a fundamentally broken concept.

Cheers,
Dave.

On Sun, Feb 21, 2016 at 1:23 PM, Boaz Harrosh <[email protected]> wrote:

Quoted 2 lines

I have manually tested all this and it seems to work. Can you see a theoretical scenario where it would not?

I'm worried about the scenario where the pmem aware app assumes that none of the cachelines in its mapping are dirty when it goes to issue pcommit. We'll have two applications with different perceptions of when writes are durable.

Maybe it's not a problem in practice, at
least current generation x86 cpus flush existing dirty cachelines when performing non-temporal stores. However, it bothers me that there are cpus where a pmem-unaware app could prevent a pmem-aware app from making writes durable. It seems if one app has established a MAP_PMEM_AWARE mapping it needs guarantees that all apps participating in that shared mapping have the same awareness.

Another potential issue is that MAP_PMEM_AWARE is not enough on its own. If the filesystem or inode does not support DAX the application needs to assume page cache semantics. At a minimum MAP_PMEM_AWARE requests would need to fail if DAX is not available.

Quoted 4 lines

Another potential issue is that MAP_PMEM_AWARE is not enough on its own. If the filesystem or inode does not support DAX the application needs to assume page cache semantics. At a minimum MAP_PMEM_AWARE requests would need to fail if DAX is not available.

They will always still need to call msync()/fsync() to guarantee data integrity, because the filesystem metadata that indexes the data still needs to be committed before data integrity can be guaranteed. i.e. MAP_PMEM_AWARE by itself it not sufficient for data integrity, and so the app will have to be written like any other app that uses page cache based mmap().

Indeed, the application cannot even assume that a fully allocated file does not require msync/fsync because the filesystem may be doing things like dedupe, defrag, copy on write, etc behind the back of the application and so file metadata changes may still be in volatile RAM even though the application has flushed it's data.

Applications have no idea what the underlying filesystem and storage is doing and so they cannot assume that complete data integrity is provided by userspace driven CPU cache flush instructions on their file data.

Quoted 2 lines

of the application and so file metadata changes may still be in volatile RAM even though the application has flushed it's data.

Once you hand out a persistent memory mapping, you sure as heck can't switch blocks around behind the back of the application.

But even if we're not dealing with persistent memory, you seem to imply that applications needs to fsync just in case the file system did something behind its back. In other words, an application opening a fully allocated file and using fdatasync will also need to call fsync, just in case. Is that really what you're suggesting?

Quoted 4 lines

Applications have no idea what the underlying filesystem and storage is doing and so they cannot assume that complete data integrity is provided by userspace driven CPU cache flush instructions on their file data.

This is surprising to me, and goes completely against the proposed programming model. In fact, this is a very basic tenet of the operation of the nvml libraries on pmem.io.

An application creates a file and writes to every single block in the thing, sync's it, closes it. It then opens it back up, calls mmap with this new MAP_DAX flag or on a file system mounted with -o dax, and proceeds to access the file using loads and stores. It persists its data by using non-temporal stores, flushing and fencing cpu instructions.

If I understand you correctly, you're saying that that application is not written correctly, because it needs to call fsync to persist metadata (that it presumably did not modify). Is that right?

Quoted 5 lines · Jeff Moyer

Quoted 2 lines

of the application and so file metadata changes may still be in volatile RAM even though the application has flushed it's data.

Once you hand out a persistent memory mapping, you sure as heck can't switch blocks around behind the back of the application.

You might not even have allocated the blocks at the time of the mmap, although for pmem remapping it after a page fault has actually allocated the block would be rather painful.

Quoted 5 lines

But even if we're not dealing with persistent memory, you seem to imply that applications needs to fsync just in case the file system did something behind its back. In other words, an application opening a fully allocated file and using fdatasync will also need to call fsync, just in case. Is that really what you're suggesting?

You above statement looks rather confused. The only difference between fdatasync and sync is that the former does not write out metadata not required to find the file data (usually that's just timestamps). So if you already use fdatasync or msync properly you don't need to fsync again. But you need to use one of the above methods to ensure your data is persistent on the medium.

Quoted 7 lines

An application creates a file and writes to every single block in the thing, sync's it, closes it. It then opens it back up, calls mmap with this new MAP_DAX flag or on a file system mounted with -o dax, and proceeds to access the file using loads and stores. It persists its data by using non-temporal stores, flushing and fencing cpu instructions.

Quoted 3 lines

If I understand you correctly, you're saying that that application is not written correctly, because it needs to call fsync to persist metadata (that it presumably did not modify). Is that right?

Exactly.

Sorry for being dense, but why, exactly? If the file system is making changes without the application's involvement, then the file system should be responsible for ensuring its own consistency, irrespective of whether the application issues an fsync. Clearly I'm missing some key point here.

Quoted 5 lines · Jeff Moyer

Sorry for being dense, but why, exactly? If the file system is making changes without the application's involvement, then the file system should be responsible for ensuring its own consistency, irrespective of whether the application issues an fsync. Clearly I'm missing some key point here.

The simplest example is a copy on write file system (or simply a copy on write file, which can exist with ocfs2 and will with xfs very soon), where each write will allocate a new block, which will require metadata updates.

We've built the whole I/O model around the concept that by default our I/O will required fsync/msync. For read/write-style I/O you can opt out using O_DSYNC. There currently is no way to opt out for memory mapped I/O, mostly because it's

a) useless without something like DAX, and
b) much harder to implement

So a MAP_SYNC option might not be entirely off the table, but I think it would be a lot of hard work and I'm not even sure it's possible to handle it in the general case.

Quoted 3 lines

This is surprising to me, and goes completely against the proposed programming model. In fact, this is a very basic tenet of the operation of the nvml libraries on pmem.io.

It's simply impossible to provide. But then again pmem.io seems to be much more about hype than reality anyway.

Hi, Dave,

Quoted 12 lines · Dave Chinner

Quoted 4 lines

Another potential issue is that MAP_PMEM_AWARE is not enough on its own. If the filesystem or inode does not support DAX the application needs to assume page cache semantics. At a minimum MAP_PMEM_AWARE requests would need to fail if DAX is not available.

They will always still need to call msync()/fsync() to guarantee data integrity, because the filesystem metadata that indexes the data still needs to be committed before data integrity can be guaranteed. i.e. MAP_PMEM_AWARE by itself it not sufficient for data integrity, and so the app will have to be written like any other app that uses page cache based mmap().

Quoted 5 lines

Indeed, the application cannot even assume that a fully allocated file does not require msync/fsync because the filesystem may be doing things like dedupe, defrag, copy on write, etc behind the back of the application and so file metadata changes may still be in volatile RAM even though the application has flushed it's data.

Once you hand out a persistent memory mapping, you sure as heck can't switch blocks around behind the back of the application.

That aside, let me see if I understand you correctly.

An application creates a file and writes to every single block in the thing, sync's it, closes it. It then opens it back up, calls mmap with this new MAP_DAX flag or on a file system mounted with -o dax, and proceeds to access the file using loads and stores. It persists its data by using non-temporal stores, flushing and fencing cpu instructions.

If I understand you correctly, you're saying that that application is not written correctly, because it needs to call fsync to persist metadata (that it presumably did not modify). Is that right?

I see. So, at write fault time, you're saying that new blocks may be allocated, and that in order to make that persistent, we need a sync operation.

Presumably this MAP_SYNC option could sync out the necessary metadata updates to the log before returning from the write fault handler. The arguments against making this work are that it isn't generally useful, and that we don't want more dax special cases in the code. Did I get that right?

I think several things are getting mixed together in this discussion:

First, one primary reason DAX exists is so that applications can access persistence directly.

Once mappings are set up, latency-sensitive apps get load/store access and can flush stores themselves using instructions rather than kernel calls.

Second, programming to load/store persistence is tricky, but the usual API for programming to memory-mapped files will "just work" and we built on that to avoid needlessly creating new permission & naming models.

If you want to use msync() or fsync(), it will work, but may not perform as well as using the instructions.

The instructions give you very fine-grain flushing control, but the downside is that the app must track what it changes at that fine granularity. Both models work, but there's a trade-off.

[Hi Andy - care to properly line break after ~75 character, that makes ready the message a lot easier, thanks!]

Quoted 3 lines

The instructions give you very fine-grain flushing control, but the downside is that the app must track what it changes at that fine granularity. Both models work, but there's a trade-off.

No, the cache flush model simply does not work without a lot of hard work to enable it first.

Quoted 3 lines

[Hi Andy - care to properly line break after ~75 character, that makes ready the message a lot easier, thanks!]

My bad.

Quoted 6 lines

Quoted 3 lines

The instructions give you very fine-grain flushing control, but the downside is that the app must track what it changes at that fine granularity. Both models work, but there's a trade-off.

No, the cache flush model simply does not work without a lot of hard work to enable it first.

It's working well enough to pass tests that simulate crashes and various workload tests for the apps involved. And I agree there has been a lot of hard work behind it. I guess I'm not sure why you're saying it is impossible or not working.

Let's take an example: an app uses fallocate() to create a DAX file, mmap() to map it, msync() to flush changes. The app follows POSIX meaning it doesn't expect file metadata to be flushed magically, etc. The app is tested carefully and it works correctly. Now the msync() call used to flush stores is replaced by flushing instructions. What's broken?

Hi, Dave,

Quoted 12 lines · Dave Chinner

Quoted 4 lines

Another potential issue is that MAP_PMEM_AWARE is not enough on its own. If the filesystem or inode does not support DAX the application needs to assume page cache semantics. At a minimum MAP_PMEM_AWARE requests would need to fail if DAX is not available.

They will always still need to call msync()/fsync() to guarantee data integrity, because the filesystem metadata that indexes the data still needs to be committed before data integrity can be guaranteed. i.e. MAP_PMEM_AWARE by itself it not sufficient for data integrity, and so the app will have to be written like any other app that uses page cache based mmap().

Quoted 5 lines

Indeed, the application cannot even assume that a fully allocated file does not require msync/fsync because the filesystem may be doing things like dedupe, defrag, copy on write, etc behind the back of the application and so file metadata changes may still be in volatile RAM even though the application has flushed it's data.

Once you hand out a persistent memory mapping, you sure as heck can't switch blocks around behind the back of the application.

But even if we're not dealing with persistent memory, you seem to imply that applications needs to fsync just in case the file system did something behind its back. In other words, an application opening a fully allocated file and using fdatasync will also need to call fsync, just in case. Is that really what you're suggesting?

Quoted 4 lines

Applications have no idea what the underlying filesystem and storage is doing and so they cannot assume that complete data integrity is provided by userspace driven CPU cache flush instructions on their file data.

This is surprising to me, and goes completely against the proposed programming model. In fact, this is a very basic tenet of the operation of the nvml libraries on pmem.io.

That aside, let me see if I understand you correctly.

An application creates a file and writes to every single block in the thing, sync's it, closes it. It then opens it back up, calls mmap with this new MAP_DAX flag or on a file system mounted with -o dax, and proceeds to access the file using loads and stores. It persists its data by using non-temporal stores, flushing and fencing cpu instructions.

If I understand you correctly, you're saying that that application is not written correctly, because it needs to call fsync to persist metadata (that it presumably did not modify). Is that right?

-Jeff

And this is BS. Using msync or fsync might not perform as well as not actually using them, but without them you do not get persistence. If you use your pmem as a throw away cache that's fine, but for most people that is not the case.

Quoted 11 lines

An application creates a file and writes to every single block in the thing, sync's it, closes it. It then opens it back up, calls mmap with this new MAP_DAX flag or on a file system mounted with -o dax, and proceeds to access the file using loads and stores. It persists its data by using non-temporal stores, flushing and fencing cpu instructions.

If I understand you correctly, you're saying that that application is not written correctly, because it needs to call fsync to persist metadata (that it presumably did not modify). Is that right?

Hi Jeff

I do not understand why you chose to drop my email address from your reply? What do I need to feel when this happens?

And to your questions above. As I answered to Dave.
This is the novelty of my approach and the big difference between
what you guys thought with MAP_DAX and my patches as submitted.
1. Application will/need to call m/fsync to let the FS the freedom it needs
2. The m/fsync as well as the page faults will be very light wait and fast, all that is required from the pmem aware app is to do movnt stores and cl_flushes.

So enjoying both worlds. And actually more:
With your approach of fallocat(ing) the all space in advance you might as well just partition the storage and use the DAX(ed) block device. But with my approach you need not pre-allocate and enjoy the over provisioned model and the space allocation management of a modern FS. And even with all that still enjoy very fast direct mapped stores by not requiring the current slow m/fsync()

I hope you guys stand behind me in my effort to accelerate userspace pmem apps and still not break any built in assumptions.

On 02/23/2016 11:52 AM, Christoph Hellwig wrote:

Please tell me what you find wrong with my approach?

Quoted 1 line · Boaz Harrosh

On 02/23/2016 11:52 AM, Christoph Hellwig wrote:

[..]

Quoted 1 line

Please tell me what you find wrong with my approach?

Setting aside fs interactions you didn't respond to my note about architectures where the pmem-aware app needs to flush caches due to other non-pmem aware apps sharing the mapping. Non-temporal stores guaranteeing persistence on their own is an architecture specific feature. I don't see how we can have a generic support for mixed MAP_PMEM_AWARE / unaware shared mappings when the architecture dependency exists [1].

I think Christoph has already pointed out the roadmap. Get the existing crop of DAX bugs squashed and then *maybe* look at something like a MAP_SYNC to opt-out of userspace needing to call *sync.

[1]: 10.4.6.2 Caching of Temporal vs. Non-Temporal Data "Some older CPU implementations (e.g., Pentium M) allowed addresses being written with a non-temporal store instruction to be updated in-place if the memory type was not WC and line was already in the cache."

I wouldn't be surprised if other architectures had similar constraints.

Quoted 18 lines · Andy

Quoted 3 lines

[Hi Andy - care to properly line break after ~75 character, that makes ready the message a lot easier, thanks!]

My bad.

Quoted 6 lines

Quoted 3 lines

The instructions give you very fine-grain flushing control, but the downside is that the app must track what it changes at that fine granularity. Both models work, but there's a trade-off.

No, the cache flush model simply does not work without a lot of hard work to enable it first.

It's working well enough to pass tests that simulate crashes and various workload tests for the apps involved. And I agree there has been a lot of hard work behind it. I guess I'm not sure why you're saying it is impossible or not working.

Quoted 6 lines

Let's take an example: an app uses fallocate() to create a DAX file, mmap() to map it, msync() to flush changes. The app follows POSIX meaning it doesn't expect file metadata to be flushed magically, etc. The app is tested carefully and it works correctly. Now the msync() call used to flush stores is replaced by flushing instructions. What's broken?

You haven't told the filesytem to flush any dirty metadata required to access the user data to persistent storage. If the zeroing and unwritten extent conversion that is run by the filesytem during write faults into preallocated blocks isn't persistent, then after a crash the file will read back as unwritten extents, returning zeros rather than the data that was written.

msync() calls fsync() on file back pages, which makes file metadata changes persistent. Indeed, if you read the fdatasync man page, you might have noticed that it makes explicit reference that it requires the filesystem to flush the metadata needed to access the data that is being synced. IOWs, the filesystem knows about this dirty metadata that needs to be flushed to ensure data integrity, userspace doesn't.

Not to mention that the filesystem will convert and zero much more than just a single cacheline (whole pages at minimum, could be 2MB extents for large pages, etc) so the filesystem may require CPU cache flushes over a much wider range of cachelines that the application realises are dirty and require flushing for data integrity purposes. The filesytem knows about these dirty cache lines, userspace doesn't.

IOWs, your userspace library may have made sure the data it modifies is in the physical location via your userspace CPU cache flushes, but there can be a lot of stuff it doesn't know about internal to the filesytem that also needs to be flushed to ensure data integrity is maintained.

Cheers,

Dave.

Signature · 6 lines

Dave Chinner
[email protected]
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm

On 02/23/2016 11:52 AM, Christoph Hellwig wrote:
<>

Quoted 6 lines

And this is BS. Using msync or fsync might not perform as well as not actually using them, but without them you do not get persistence. If you use your pmem as a throw away cache that's fine, but for most people that is not the case.

Hi Christoph

So is exactly my suggestion. My approach is *not* the we do not call m/fsync to let the FS clean up.

In my model we still do that, only we eliminate the m/fsync slowness and the all page faults overhead by being instructed by the application that we do not need to track the data modified cachelines. Since the application is telling us that it will do so.

In my model the job is split:
App will take care of data persistence by instructing a MAP_PMEM_AWARE, and doing its own cl_flushing / movnt.
Which is the heavy cost

The FS will keep track of the Meta-Data persistence as it already does, via the call to m/fsync. Which is marginal performance compared to the above heavy IO.

Note that the FS is still free to move blocks around, as Dave said:
lockout pagefaultes, unmap from user space, let app fault again on a new block. this will still work as before, already in COW we flush the old block so there will be no persistence lost.

So this all thread started with my patches, and my patches do not say "no m/fsync" they say, make this 3-8 times faster than today if the app is participating in the heavy lifting.

Please tell me what you find wrong with my approach?

Quoted 23 lines · Dan Williams

Quoted 1 line · Boaz Harrosh

On 02/23/2016 11:52 AM, Christoph Hellwig wrote:

[..]

Quoted 1 line

Please tell me what you find wrong with my approach?

Setting aside fs interactions you didn't respond to my note about architectures where the pmem-aware app needs to flush caches due to other non-pmem aware apps sharing the mapping. Non-temporal stores guaranteeing persistence on their own is an architecture specific feature. I don't see how we can have a generic support for mixed MAP_PMEM_AWARE / unaware shared mappings when the architecture dependency exists [1].

I think Christoph has already pointed out the roadmap. Get the existing crop of DAX bugs squashed and then *maybe* look at something like a MAP_SYNC to opt-out of userspace needing to call *sync.

[1]: 10.4.6.2 Caching of Temporal vs. Non-Temporal Data "Some older CPU implementations (e.g., Pentium M) allowed addresses being written with a non-temporal store instruction to be updated in-place if the memory type was not WC and line was already in the cache."

Quoted 1 line

I wouldn't be surprised if other architectures had similar constraints.

I don't understand how this is an argument against Boaz's approach. If non-temporal stores are essentially broken, they are broken for both the kernel use case and for the userspace use case, and (if we want to support these platforms, which I'm not sure we do) we would need to fall back to writes + explicit flushes for both kernel space and userspace.

Quoted 8 lines · Dave Chinner

On Tue, Feb 23, 2016 at 10:07:07AM +0000, Rudoff, Andy wrote:
Not to mention that the filesystem will convert and zero much more than just a single cacheline (whole pages at minimum, could be 2MB extents for large pages, etc) so the filesystem may require CPU cache flushes over a much wider range of cachelines that the application realises are dirty and require flushing for data integrity purposes. The filesytem knows about these dirty cache lines, userspace doesn't.

With the current code at least dax_zero_page_range() doesn't rely

on fsync/msync from userspace to make the zeroes that it writes persistent. It does all the necessary flushing and wmb_pmem() calls itself.

I agree that this does not address your concern
about metadata being in sync, though.

Quoted 1 line · Boaz Harrosh

On 02/23/2016 11:52 AM, Christoph Hellwig wrote:

[..]

Quoted 1 line

Please tell me what you find wrong with my approach?

Setting aside fs interactions you didn't respond to my note about architectures where the pmem-aware app needs to flush caches due to other non-pmem aware apps sharing the mapping. Non-temporal stores guaranteeing persistence on their own is an architecture specific feature. I don't see how we can have a generic support for mixed MAP_PMEM_AWARE / unaware shared mappings when the architecture dependency exists [1].

I think Christoph has already pointed out the roadmap. Get the existing crop of DAX bugs squashed

and then *maybe* look at something
like a MAP_SYNC to opt-out of userspace needing to call *sync.

[1]: 10.4.6.2 Caching of Temporal vs. Non-Temporal Data "Some older CPU implementations (e.g., Pentium M) allowed addresses being written with a non-temporal store instruction to be updated in-place if the memory type was not WC and line was already in the cache."

I wouldn't be surprised if other architectures had similar constraints.

i.e. what we've implemented right now is a basic, slow, easy-to-make-work-correctly brute force solution. That doesn't mean we always need to implement it this way, or that we are bound by the way dax_clear_sectors() currently flushes cachelines before it returns. It's just a simple implementation that provides the ordering the *filesystem requires* to provide the correct data integrity semantics to userspace.

But seriously please explain the problem. I do not see one.

Quoted 2 lines

I think Christoph has already pointed out the roadmap. Get the existing crop of DAX bugs squashed

Sure that's always true, I'm a stability freak through and through ask the guys who work with me. I like to sleep at night ;-)

Quoted 3 lines

and then *maybe* look at something
like a MAP_SYNC to opt-out of userspace needing to call *sync.

MAP_SYNC Is another novelty, which as Dave showed will not be implemented by such a legacy filesystem as xfs. any time soon. sync is needed not only for memory stores. For me this is a supper set of what I proposed. because again any file writes persistence is built of two parts durable data, and durable meta-data. My flag says, app takes care of data, then the other part can be done another way. For performance sake which is what I care about the heavy lifting is done at the data path. the meta data is marginal. If you want for completeness sake then fine have another flag.

The new app written will need to do its new pmem_memcpy magic any way. then we are saying "do we need to call fsync() or not?"

I hate it that you postpone that to never because it would be nice for philosophical sake to not have the app call sync at all. and all these years suffer the performance penalty. Instead of putting in a 10 liners patch today that has no risks, and yes forces new apps to keep the ugly fsync() call, but have the targeted performance today instead of *maybe* never.

my path is a nice intermediate progression to yours. Yours blocks my needs indefinitely?

Quoted 8 lines

[1]: 10.4.6.2 Caching of Temporal vs. Non-Temporal Data "Some older CPU implementations (e.g., Pentium M) allowed addresses being written with a non-temporal store instruction to be updated in-place if the memory type was not WC and line was already in the cache."

I wouldn't be surprised if other architectures had similar constraints.

Perhaps you are looking at this from the wrong perspective. Pentium M can do this because the two cores shared the same cache. But we are talking about POSIX files semantics. Not CPU memory semantics. Some of our problems go away.

Or am I missing something out and I'm completely clueless. Please explain slowly.

It seems like we are trying to solve a couple of different problems:

1) Make page faults faster by skipping any radix tree insertions, tag updates, etc.

2) Make fsync/msync faster by not flushing data that the application says it is already making durable from userspace.

I agree that your approach seems to improve both of these problems, but I would argue that it is an incomplete solution for problem #2 because a fsync/msync from the PMEM aware application would still flush any radix tree entries from *other* threads that were writing to the same file.

It seems like a more direct solution for #2 above would be to have a metadata-only equivalent of fsync/fdatasync, say "fmetasync", which says "I'll make the writes I do to my mmaps durable from userspace, but I need you to sync all filesystem metadata for me, please".

This would allow a complete separation of data synchronization in userspace from metadata synchronization in kernel space by the filesystem code.

By itself a fmetasync() type solution of course would do nothing for issue #1
- if that was a compelling issue you'd need something like the mmap tag you're proposing to skip work on page faults.

All that being said, though, I agree with others in the thread that we should still be focused on correctness, as we have a lot of correctness issues remaining. When we eventually get to the place where we are trying to do performance optimizations, those optimizations should be measurement driven.

- Ross

In general MAP_SYNC, makes more sense semantic sense in that the filesystem knows that the application is not going to be calling *sync and it avoids triggering flushes for cachelines we don't care about.

Although if we had MAP_SYNC today we'd still be in the situation that an app that fails to do its own cache flushes / bypass correctly gets to keep the broken pieces.

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically. If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Quoted 7 lines · Dan Williams

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically. If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

I disagree. I'm not saying any "trust me I know what I'm doing" flag. the FS reveals nothing and trusts nothing.
All I'm saying is that the libc library I'm using as the new pmem_memecpy() and I'm using that instead of the old memecpy(). So the FS does not need to wipe my face after I eat. Failing to do so just means a bug in the application

In general MAP_SYNC, makes more sense semantic sense in that the filesystem knows that the application is not going to be calling *sync

Although if we had MAP_SYNC today we'd still be in the situation that an app that fails to do its own cache flushes / bypass correctly gets to keep the broken pieces.

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically.

If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

On 02/23/2016 11:47 PM, Dave Chinner wrote:
<>

Quoted 9 lines

i.e. what we've implemented right now is a basic, slow, easy-to-make-work-correctly brute force solution. That doesn't mean we always need to implement it this way, or that we are bound by the way dax_clear_sectors() currently flushes cachelines before it returns. It's just a simple implementation that provides the ordering the *filesystem requires* to provide the correct data integrity semantics to userspace.

Or it can be written properly with movnt instructions and be even faster the a simple memset, and no need for any cl_flushing let alone any radix-tree locking.

That said your suggestion above is 25%-100% slower than current code because the cl_flushes will be needed eventually, and the atomics of a lock takes 25% the time of a full page copy.

You are forgetting we are
talking about memory and not harddisk. the rules are different.

Quoted 3 lines

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically.

The file system already trusts that. If an application doesn't use fsync properly, guess what, it will break. This line of reasoning doesn't make any sense to me.

Quoted 3 lines

If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm doing" interface, right?

Quoted 10 lines · Boaz Harrosh

Quoted 7 lines · Dan Williams

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically. If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Quoted 5 lines

I disagree. I'm not saying any "trust me I know what I'm doing" flag. the FS reveals nothing and trusts nothing.
All I'm saying is that the libc library I'm using as the new pmem_memecpy() and I'm using that instead of the old memecpy(). So the FS does not need to wipe my face after I eat. Failing to do so just means a bug in the application

"just means a bug in the application"

Who gets the bug report when an app gets its cache syncing wrong and data corruption ensues, and why isn't the fix for that bug that the filesystem simply stops trusting MAP_PMEM_AWARE and synching cachelines on behalf of the app when it calls sync as it must for metadata consistency. Problem solved globally for all broken usages of MAP_PMEM_AWARE and the flag loses all meaning as a result.

This is the takeaway I've internalized from Dave's pushback of these new mmap flags.

Quoted 7 lines · Jeff Moyer

Quoted 3 lines

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically.

The file system already trusts that. If an application doesn't use fsync properly, guess what, it will break. This line of reasoning doesn't make any sense to me.

No, I'm worried about the case where an app specifies MAP_PMEM_AWARE uses fsync correctly, and fails to flush cpu cache.

Quoted 6 lines

Quoted 3 lines

If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm doing" interface, right?

It is the "I know what I'm doing" interface, MAP_PMEM_AWARE asserts "I know when to flush the cpu relative to an fsync()".

Quoted 11 lines · Dan Williams

Quoted 7 lines · Jeff Moyer

Quoted 3 lines

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically.

The file system already trusts that. If an application doesn't use fsync properly, guess what, it will break. This line of reasoning doesn't make any sense to me.

No, I'm worried about the case where an app specifies MAP_PMEM_AWARE uses fsync correctly, and fails to flush cpu cache.

I don't think the kernel needs to put training wheels on applications.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm doing" interface, right?

It is the "I know what I'm doing" interface, MAP_PMEM_AWARE asserts "I know when to flush the cpu relative to an fsync()".

I see. So I think your argument is that new file systems (such as Nova) can have whacky new semantics, but existing file systems should provide the more conservative semantics that they have provided since the dawn of time (even if we add a new mmap flag to control the behavior).

I don't agree with that. :)

Quoted 17 lines · Dan Williams

Quoted 10 lines · Boaz Harrosh

Quoted 7 lines · Dan Williams

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically. If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Quoted 5 lines

I disagree. I'm not saying any "trust me I know what I'm doing" flag. the FS reveals nothing and trusts nothing.
All I'm saying is that the libc library I'm using as the new pmem_memecpy() and I'm using that instead of the old memecpy(). So the FS does not need to wipe my face after I eat. Failing to do so just means a bug in the application

Quoted 9 lines

"just means a bug in the application"

Who gets the bug report when an app gets its cache syncing wrong and data corruption ensues, and why isn't the fix for that bug that the filesystem simply stops trusting MAP_PMEM_AWARE and synching cachelines on behalf of the app when it calls sync as it must for metadata consistency. Problem solved globally for all broken usages of MAP_PMEM_AWARE and the flag loses all meaning as a result.

Because this will not fix the application's bugs. Because if the application is broken then you do not know that this will fix it. It is broken it failed to uphold the contract it had with the Kernel.

It is like saying lets call fsync on file close because broken apps keep forgetting to call fsync(). And file close is called even if the app crashes. Will Dave do that?

No if an app has a bug like this falling to call the proper pmem_xxx routine in the proper work flow, it might has just forgotten to call fsync, or maybe still modifying memory after fsync was called. And your babysitting the app will not help.

Quoted 3 lines

This is the takeaway I've internalized from Dave's pushback of these new mmap flags.

We are already used to tell the firefox guys, you did not call fsync and you lost data on a crash.

We will have a new mantra, "You did not use pmem_memcpy() but used MAP_PMEM_AWARE" We have contracts like that between Kernel and apps all the time. I fail to see why this one crossed the line for you?

Quoted 12 lines · Boaz Harrosh

On 02/23/2016 11:47 PM, Dave Chinner wrote:
<>

Quoted 9 lines

i.e. what we've implemented right now is a basic, slow, easy-to-make-work-correctly brute force solution. That doesn't mean we always need to implement it this way, or that we are bound by the way dax_clear_sectors() currently flushes cachelines before it returns. It's just a simple implementation that provides the ordering the *filesystem requires* to provide the correct data integrity semantics to userspace.

Quoted 3 lines

Or it can be written properly with movnt instructions and be even faster the a simple memset, and no need for any cl_flushing let alone any radix-tree locking.

Precisely my point - semantics of persistent memory durability are going to change from kernel to kernel, architecture to architecture, and hardware to hardware.

Assuming applications are going to handle all these wacky differences to provide their users with robust data integrity is a recipe for disaster. If applications writers can't even use fsync properly, I can guarantee you they are going to completely fuck up data integrity when targeting pmem.

Quoted 3 lines

That said your suggestion above is 25%-100% slower than current code because the cl_flushes will be needed eventually, and the atomics of a lock takes 25% the time of a full page copy.

So what? We can optimise for performance later, once we've provided correct and resilient infrastructure. We've been fighting against premature optimisation for performance from teh start with DAX - we've repeatedly had to undo stuff that was fast but broken, and were not doing that any more. Correctness comes first, then we can address the performance issues via iterative improvement, like we do with everything else.

Quoted 2 lines

You are forgetting we are
talking about memory and not harddisk. the rules are different.

That's bullshit, Boaz. I'm sick and tired of people saying "but pmem is different" as justification for not providing correct, reliable data integrity behaviour. Filesytems on PMEM have to follow all the same rules as any other type of persistent storage we put filesystems on.

Yes, the speed of the storage may expose the fact that am unoptimised correct implementation is a lot more expensive than ignoring correctness, but that does not mean we can ignore correctness. Nor does it mean that a correct implementation will be slow - it just means we haven't optimised for speed yet because getting it correct is a hard problem and our primary focus.

Cheers,

Dave.

Quoted 31 lines · Jeff Moyer

Quoted 11 lines · Dan Williams

Quoted 7 lines · Jeff Moyer

Quoted 3 lines

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically.

The file system already trusts that. If an application doesn't use fsync properly, guess what, it will break. This line of reasoning doesn't make any sense to me.

No, I'm worried about the case where an app specifies MAP_PMEM_AWARE uses fsync correctly, and fails to flush cpu cache.

I don't think the kernel needs to put training wheels on applications.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm doing" interface, right?

It is the "I know what I'm doing" interface, MAP_PMEM_AWARE asserts "I know when to flush the cpu relative to an fsync()".

I see. So I think your argument is that new file systems (such as Nova) can have whacky new semantics, but existing file systems should provide the more conservative semantics that they have provided since the dawn of time (even if we add a new mmap flag to control the behavior).

Quoted 2 lines

I don't agree with that. :)

Fair enough. Recall, I was pushing MAP_DAX not to long ago. It just seems like a Sisyphean effort to push an mmap flag up the XFS hill and maybe that effort is better spent somewhere else.

Quoted 7 lines

I see. So I think your argument is that new file systems (such as Nova) can have whacky new semantics, but existing file systems should provide the more conservative semantics that they have provided since the dawn of time (even if we add a new mmap flag to control the behavior).

I don't agree with that. :)

Fair enough. Recall, I was pushing MAP_DAX not to long ago. It just seems like a Sisyphean effort to push an mmap flag up the XFS hill and maybe that effort is better spent somewhere else.

Quoted 32 lines · Dan Williams

Quoted 31 lines · Jeff Moyer

Quoted 11 lines · Dan Williams

Quoted 7 lines · Jeff Moyer

Quoted 3 lines

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically.

The file system already trusts that. If an application doesn't use fsync properly, guess what, it will break. This line of reasoning doesn't make any sense to me.

No, I'm worried about the case where an app specifies MAP_PMEM_AWARE uses fsync correctly, and fails to flush cpu cache.

I don't think the kernel needs to put training wheels on applications.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm doing" interface, right?

It is the "I know what I'm doing" interface, MAP_PMEM_AWARE asserts "I know when to flush the cpu relative to an fsync()".

I see. So I think your argument is that new file systems (such as Nova) can have whacky new semantics, but existing file systems should provide the more conservative semantics that they have provided since the dawn of time (even if we add a new mmap flag to control the behavior).

Quoted 6 lines

Quoted 2 lines

I don't agree with that. :)

Fair enough. Recall, I was pushing MAP_DAX not to long ago. It just seems like a Sisyphean effort to push an mmap flag up the XFS hill and maybe that effort is better spent somewhere else.

Well, for what it's worth MAP_SYNC feels like the "right" solution to me. I understand that we are a ways from having it implemented, but it seems like the correct way to have applications work with persistent memory in a perfect world, and worth the effort.

MAP_PMEM_AWARE is interesting, but even in a perfect world it seems like a partial solution - applications still need to call *sync to get the FS metadata to be durable, and they have no reliable way of knowing which of their actions will cause the metadata to be out of sync.

Dave, is your objection to the MAP_SYNC idea a practical one about complexity and time to get it implemented, or do you think it's is the wrong solution?

Quoted 11 lines · Dan Williams

Quoted 7 lines

I see. So I think your argument is that new file systems (such as Nova) can have whacky new semantics, but existing file systems should provide the more conservative semantics that they have provided since the dawn of time (even if we add a new mmap flag to control the behavior).

I don't agree with that. :)

Fair enough. Recall, I was pushing MAP_DAX not to long ago. It just seems like a Sisyphean effort to push an mmap flag up the XFS hill and maybe that effort is better spent somewhere else.

Given Dave's last response to Boaz, I see what you mean, and I also understand Dave's reasoning better, now. FWIW, I never disagreed with spending effort elsewhere for now. I did think that the mmap flag was on the horizon, though. From Dave's comments, I think the prospects of that are slim to none. That's fine, at least we have a definite direction. Time to update all of the slide decks. =)

From this perspective, I'd much prefer that we look to generic

On Tue, Feb 23, 2016 at 03:56:17PM -0800, Dan Williams wrote:

MAP_PMEM_AWARE is interesting, but even in a perfect world it seems like a partial solution - applications still need to call *sync to get the FS metadata to be durable, and they have no reliable way of knowing which of their actions will cause the metadata to be out of sync.

Dave, is your objection to the MAP_SYNC idea a practical one about complexity and time to get it implemented, or do you think it's is the wrong solution?

_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm

Quoted 45 lines · Ross Zwisler

Quoted 32 lines · Dan Williams

Quoted 31 lines · Jeff Moyer

Quoted 11 lines · Dan Williams

Quoted 7 lines · Jeff Moyer

Quoted 3 lines

The crux of the problem, in my opinion, is that we're asking for an "I know what I'm doing" flag, and I expect that's an impossible statement for a filesystem to trust generically.

The file system already trusts that. If an application doesn't use fsync properly, guess what, it will break. This line of reasoning doesn't make any sense to me.

No, I'm worried about the case where an app specifies MAP_PMEM_AWARE uses fsync correctly, and fails to flush cpu cache.

I don't think the kernel needs to put training wheels on applications.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the opinion that the "I know what I'm doing" interface should be something separate from today's trusted filesystems.

Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm doing" interface, right?

It is the "I know what I'm doing" interface, MAP_PMEM_AWARE asserts "I know when to flush the cpu relative to an fsync()".

I see. So I think your argument is that new file systems (such as Nova) can have whacky new semantics, but existing file systems should provide the more conservative semantics that they have provided since the dawn of time (even if we add a new mmap flag to control the behavior).

Quoted 6 lines

Quoted 2 lines

I don't agree with that. :)

Fair enough. Recall, I was pushing MAP_DAX not to long ago. It just seems like a Sisyphean effort to push an mmap flag up the XFS hill and maybe that effort is better spent somewhere else.

Well, for what it's worth MAP_SYNC feels like the "right" solution to me. I understand that we are a ways from having it implemented, but it seems like the correct way to have applications work with persistent memory in a perfect world, and worth the effort.

Quoted 7 lines

MAP_PMEM_AWARE is interesting, but even in a perfect world it seems like a partial solution - applications still need to call *sync to get the FS metadata to be durable, and they have no reliable way of knowing which of their actions will cause the metadata to be out of sync.

Dave, is your objection to the MAP_SYNC idea a practical one about complexity and time to get it implemented, or do you think it's is the wrong solution?

Jan, I just noticed that this chain didn't CC you nor linux-fsdevel, so you may have missed it. All the gory details are here:

http://thread.gmane.org/gmane.linux.kernel.mm/146691

Let me provide a little background for my question. (Everyone else on the thread feel free to jump in if you feel like my summary is incorrect or incomplete.)

There is a new persistent memory programming model outlined on pmem.io and implemented by the NVM Library (nvml).

http://pmem.io/
http://pmem.io/nvml/
https://github.com/pmem/nvml/

This new programming model is based on the idea that an application should be able to create a DAX MMAP, and then from then on satisfy the data durability requirements of the application purely in userspace. This is done by using non-temporal stores or cached writes followed by flushes, the same way that we do things in the kernel.

Dave was concerned that this breaks down for XFS because even if the application were to sync all its writes to media, the filesystem could be making associated metadata changes that the application wouldn't and couldn't know about:

http://article.gmane.org/gmane.linux.kernel.mm/146699

To sync these metadata changes to media, the application would still need to call *sync.

One proposal from Christoph was that we could add a MMAP_SYNC flag that essentially says "make all metadata operations synchronous":

http://article.gmane.org/gmane.linux.kernel.mm/146753

The worry is that this would be complex to implement, and that we maybe don't want yet another DAX special case in the FS code.

Another way that we could implement this would be to key off of the DAX mount option / inode setting for all mmaps that use DAX. This would preclude the need for changes to the mmap() API.

My question: How far away are we from having such a metadata durability guarantee in ext4? Do we have cases where the metadata changes associated with a page fault, etc. could be out of sync with the data writes that are being made durable by the application in userspace?

I see ext4 creating journal entries around page faults in places like ext4_dax_fault() - this should durably record any metadata changes associated with that page fault before the fault completes, correct?

Are there other cases you can think of with ext4 where we would need to call *sync for DAX just to be sure we are safely synchronizing metadata?

Well, let me clarify what I said a bit here, because I feel like I'm being unfairly blamed for putting data integrity as the highest priority for DAX+pmem instead of falling in line and chanting "Performance! Performance! Performance!" with everyone else.

Let me state this clearly: I'm not opposed to making optimisations that change the way applications and the kernel interact. I like the idea of MAP_SYNC, but I see this sort of API/behaviour change as a last resort when all else fails, not a "first and only" optimisation option.

The big issue we have right now is that we haven't made the DAX/pmem infrastructure work correctly and reliably for general use. Hence adding new APIs to workaround cases where we haven't yet provided correct behaviour, let alone optimised for performance is, quite frankly, a clear case premature optimisation.

Quoted 5 lines

The big issue we have right now is that we haven't made the DAX/pmem infrastructure work correctly and reliably for general use. Hence adding new APIs to workaround cases where we haven't yet provided correct behaviour, let alone optimised for performance is, quite frankly, a clear case premature optimisation.

Again, I see the two things as separate issues. You need both. Implementing MAP_SYNC doesn't mean we don't have to solve the bigger issue of making existing applications work safely.

Quoted 9 lines · Jeff Moyer

Quoted 5 lines

The big issue we have right now is that we haven't made the DAX/pmem infrastructure work correctly and reliably for general use. Hence adding new APIs to workaround cases where we haven't yet provided correct behaviour, let alone optimised for performance is, quite frankly, a clear case premature optimisation.

Again, I see the two things as separate issues. You need both. Implementing MAP_SYNC doesn't mean we don't have to solve the bigger issue of making existing applications work safely.

I want to add one more thing to this discussion, just for the sake of clarity. When I talk about existing applications and pmem, I mean applications that already know how to detect and recover from torn sectors. Any application that assumes hardware does not tear sectors should be run on a file system layered on top of the btt.

Quoted 12 lines · Jeff Moyer

Quoted 9 lines · Jeff Moyer

Quoted 5 lines

The big issue we have right now is that we haven't made the DAX/pmem infrastructure work correctly and reliably for general use. Hence adding new APIs to workaround cases where we haven't yet provided correct behaviour, let alone optimised for performance is, quite frankly, a clear case premature optimisation.

Again, I see the two things as separate issues. You need both. Implementing MAP_SYNC doesn't mean we don't have to solve the bigger issue of making existing applications work safely.

Quoted 5 lines

I want to add one more thing to this discussion, just for the sake of clarity. When I talk about existing applications and pmem, I mean applications that already know how to detect and recover from torn sectors. Any application that assumes hardware does not tear sectors should be run on a file system layered on top of the btt.

Which turns off DAX, and hence makes this a moot discussion because

Keep in mind that existing storage technologies tear fileystem data writes, too, because user data writes are filesystem block sized and not atomic at the device level (i.e. typical is 512 byte sector, 4k filesystem block size, so there are 7 points in a single write where a tear can occur on a crash).

IOWs existing storage already has the capability of tearing user data on crash and has been doing so for a least they last 30 years.

Hence I really don't see any fundamental difference here with pmem+DAX - the only difference is that the tear granuarlity is smaller (CPU cacheline rather than sector).

Quoted 7 lines · Jeff Moyer

Quoted 5 lines · Jeff Moyer

Quoted 5 lines

The big issue we have right now is that we haven't made the DAX/pmem infrastructure work correctly and reliably for general use. Hence adding new APIs to workaround cases where we haven't yet provided correct behaviour, let alone optimised for performance is, quite frankly, a clear case premature optimisation.

Quoted 8 lines

Quoted 3 lines

Again, I see the two things as separate issues. You need both. Implementing MAP_SYNC doesn't mean we don't have to solve the bigger issue of making existing applications work safely.

I want to add one more thing to this discussion, just for the sake of clarity. When I talk about existing applications and pmem, I mean applications that already know how to detect and recover from torn sectors. Any application that assumes hardware does not tear sectors should be run on a file system layered on top of the btt.

Which turns off DAX, and hence makes this a moot discussion because mmap is then buffered through the page cache and hence applications *must use msync/fsync* to provide data integrity. Which also makes them safe to use with DAX if we have a working fsync.

Keep in mind that existing storage technologies tear fileystem data writes, too, because user data writes are filesystem block sized and not atomic at the device level (i.e. typical is 512 byte sector, 4k filesystem block size, so there are 7 points in a single write where a tear can occur on a crash).

IOWs existing storage already has the capability of tearing user data on crash and has been doing so for a least they last 30 years. Hence I really don't see any fundamental difference here with pmem+DAX - the only difference is that the tear granuarlity is smaller (CPU cacheline rather than sector).

Cheers,

Dave.

Hi, Dave,

Quoted 4 lines · Dave Chinner

Well, let me clarify what I said a bit here, because I feel like I'm being unfairly blamed for putting data integrity as the highest priority for DAX+pmem instead of falling in line and chanting "Performance! Performance! Performance!" with everyone else.

It's totally fair. ;-)

Quoted 5 lines

Let me state this clearly: I'm not opposed to making optimisations that change the way applications and the kernel interact. I like the idea of MAP_SYNC, but I see this sort of API/behaviour change as a last resort when all else fails, not a "first and only" optimisation option.

So, calling it "first and only" seems a bit unfair on your part.

I
don't think anyone asking for a MAP_SYNC option doesn't also want other applications to work well. That aside, this is where your opinion differs from mine: I don't see MAP_SYNC as a last resort option. And let me be clear, this /is/ an opinion. I have no hard facts to back it up, precisely because we don't have any application we can use for a comparison.

But, it seems plausible to me that no matter how well you optimize your msync implementation, it will still be more expensive than an application that doesn't call msync at all. This obviously depends on how the application is using the programming model, among other things. I agree that we would need real data to back this up. However, I don't see any reason to preclude such an implementation, or to leave it as a last resort. I think it should be part of our planning process if it's reasonably feasible.

Quoted 21 lines · Dave Chinner

Quoted 7 lines · Jeff Moyer

Quoted 5 lines · Jeff Moyer

Quoted 5 lines

The big issue we have right now is that we haven't made the DAX/pmem infrastructure work correctly and reliably for general use. Hence adding new APIs to workaround cases where we haven't yet provided correct behaviour, let alone optimised for performance is, quite frankly, a clear case premature optimisation.

Quoted 8 lines

Quoted 3 lines

Again, I see the two things as separate issues. You need both. Implementing MAP_SYNC doesn't mean we don't have to solve the bigger issue of making existing applications work safely.

I want to add one more thing to this discussion, just for the sake of clarity. When I talk about existing applications and pmem, I mean applications that already know how to detect and recover from torn sectors. Any application that assumes hardware does not tear sectors should be run on a file system layered on top of the btt.

Which turns off DAX, and hence makes this a moot discussion because mmap is then buffered through the page cache and hence applications *must use msync/fsync* to provide data integrity. Which also makes them safe to use with DAX if we have a working fsync.

Quoted 5 lines

Keep in mind that existing storage technologies tear fileystem data writes, too, because user data writes are filesystem block sized and not atomic at the device level (i.e. typical is 512 byte sector, 4k filesystem block size, so there are 7 points in a single write where a tear can occur on a crash).

Is that really true? Storage to date is on the PCIE/SATA etc IO chain. The locks and application crash scenarios when traversing down this chain are such that the device will not have its DMA programmed until the whole 4K etc page is flushed to memory, pinned

In both cases, btt is not indirecting the buffer (as for a DMA master IO type device) but is simply using the same pmem api primitives to manage its own meta data about the filesystem writes to detect and recover from tears after the event. In what sense is DAX disabled for this?

So I think (please correct me if I'm wrong) but actually the hardware/firmware guys have been fixing the torn sector problem for

Good morning, Dave,

Quoted 19 lines · Dave Chinner

Quoted 17 lines · Jeff Moyer

Quoted 9 lines · Jeff Moyer

Quoted 5 lines

The big issue we have right now is that we haven't made the DAX/pmem infrastructure work correctly and reliably for general use. Hence adding new APIs to workaround cases where we haven't yet provided correct behaviour, let alone optimised for performance is, quite frankly, a clear case premature optimisation.

Again, I see the two things as separate issues. You need both. Implementing MAP_SYNC doesn't mean we don't have to solve the bigger issue of making existing applications work safely.

I want to add one more thing to this discussion, just for the sake of clarity. When I talk about existing applications and pmem, I mean applications that already know how to detect and recover from torn sectors. Any application that assumes hardware does not tear sectors should be run on a file system layered on top of the btt.

Quoted 1 line

Which turns off DAX, and hence makes this a moot discussion because

You're missing the point. You can't take applications that don't know how to deal with torn sectors and put them on a block device that does not provide power fail write atomicity of a single sector.

Quoted 5 lines

Keep in mind that existing storage technologies tear fileystem data writes, too, because user data writes are filesystem block sized and not atomic at the device level (i.e. typical is 512 byte sector, 4k filesystem block size, so there are 7 points in a single write where a tear can occur on a crash).

You are conflating torn pages (pages being a generic term for anything greater than a sector) and torn sectors.

Quoted 2 lines

IOWs existing storage already has the capability of tearing user data on crash and has been doing so for a least they last 30 years.

And yet applications assume that this doesn't happen. Have a look at this:
https://www.sqlite.org/psow.html

Quoted 23 lines · Jeff Moyer

Good morning, Dave,

Quoted 19 lines · Dave Chinner

Quoted 17 lines · Jeff Moyer

Quoted 9 lines · Jeff Moyer

Quoted 5 lines

The big issue we have right now is that we haven't made the DAX/pmem infrastructure work correctly and reliably for general use. Hence adding new APIs to workaround cases where we haven't yet provided correct behaviour, let alone optimised for performance is, quite frankly, a clear case premature optimisation.

Again, I see the two things as separate issues. You need both. Implementing MAP_SYNC doesn't mean we don't have to solve the bigger issue of making existing applications work safely.

I want to add one more thing to this discussion, just for the sake of clarity. When I talk about existing applications and pmem, I mean applications that already know how to detect and recover from torn sectors. Any application that assumes hardware does not tear sectors should be run on a file system layered on top of the btt.

Quoted 5 lines

Quoted 1 line

Which turns off DAX, and hence makes this a moot discussion because

You're missing the point. You can't take applications that don't know how to deal with torn sectors and put them on a block device that does not provide power fail write atomicity of a single sector.

Very few applications actually care about atomic sector writes. Databases are probably the only class of application that really do care about both single sector and multi-sector atomic write behaviour, and many of them can be configured to assume single sector writes can be torn.

Torn user data writes have always been possible, and so pmem does not introduce any new semantics that applications have to handle.

Quoted 8 lines

Quoted 5 lines

Keep in mind that existing storage technologies tear fileystem data writes, too, because user data writes are filesystem block sized and not atomic at the device level (i.e. typical is 512 byte sector, 4k filesystem block size, so there are 7 points in a single write where a tear can occur on a crash).

You are conflating torn pages (pages being a generic term for anything greater than a sector) and torn sectors.

No, I'm not. I'm pointing out that applications that really care about data integrity already have the capability to recovery from torn sectors in the event of a crash. pmem+DAX does not introduce any new way of corrupting user data for these applications.

Quoted 6 lines

Quoted 2 lines

IOWs existing storage already has the capability of tearing user data on crash and has been doing so for a least they last 30 years.

And yet applications assume that this doesn't happen. Have a look at this:
https://www.sqlite.org/psow.html

Quote:

"All versions of SQLite up to and including version 3.7.9 assume that the filesystem does not provide powersafe overwrite. [...]

Hence it seems reasonable to assume powersafe overwrite for modern disks. [...] Caution is advised though. As Roger Binns noted on the SQLite developers mailing list: "'poorly written' should be the main assumption about drive firmware."

IOWs, SQLite used to always assume that single sector overwrites can be torn, and now that it is optional it recommends that users should assume this is the way their storage behaves in order to be safe. In this config, it uses the write ahead log even for single sector writes, and hence can recover from torn sector writes without having to detect that the write was torn.

Quote:

"SQLite never assumes that database page writes are atomic,
regardless of the PSOW setting.(1) And hence SQLite is always able to automatically recover from torn pages induced by a crash."

This is Because multi-sector writes are always staged through the write ahead log and hence are cleanly recoverable after a crash without having to detect whether a torn write occurred or not.

IOWs, you've just pointed to an application that demonstrates pmem-safe behaviour - just configure the database files with "file:somefile.db?psow=0" and it will assume that individual sector writes can be torn, and it will always recover.

Hence I'm not sure exactly what point you are trying to make with this example.

[ adding Thanu ]

Quoted 9 lines

Very few applications actually care about atomic sector writes. Databases are probably the only class of application that really do care about both single sector and multi-sector atomic write behaviour, and many of them can be configured to assume single sector writes can be torn.

Torn user data writes have always been possible, and so pmem does not introduce any new semantics that applications have to handle.

Quoted 11 lines · Dan Williams

[ adding Thanu ]

Quoted 9 lines

Very few applications actually care about atomic sector writes. Databases are probably the only class of application that really do care about both single sector and multi-sector atomic write behaviour, and many of them can be configured to assume single sector writes can be torn.

Torn user data writes have always been possible, and so pmem does not introduce any new semantics that applications have to handle.

I know about BTT and DAX only at a conceptual level and hence do not understand this mailing thread fully. But I can provide examples of important applications expecting atomicity at a 512B or a smaller granularity. Here is a list:

(1) LMDB [1] that Dan mentioned, which expects "linear writes" (i.e., don't need atomicity, but need the first byte to be written before the second byte)

(2) PostgreSQL expects atomicity [2]

(3) SQLite depends on linear writes [3] (we were unable to find these dependencies during our testing, however). Also, PSOW in SQLite is not relevant to this discussion as I understand it; PSOW deals with corruption of data *around* the actual written bytes.

(4) We found that ZooKeeper depends on atomicity during our testing, but we did not contact the ZooKeeper developers about this. Some details in our paper [4].

It is tempting to assume that applications do not use the concept of disk sectors and deal with only file-system blocks (which are not atomic in practice), and take measures to deal with the non-atomic file-system blocks. But, in reality, applications seem to assume that 512B (more or less) sectors are atomic or linear, and build their consistency mechanisms around that.

[1] http://www.openldap.org/list~s/openldap-devel/201410/msg00004.html
[2] http://www.postgresql.org/docs/9.5/static/wal-internals.html , "To deal with the case where pg_control is corrupt" ...
[3] https://www.sqlite.org/atomiccommit.html , "SQLite does always assume that a sector write is linear" ...
[4] http://research.cs.wisc.edu/wind/Publications/alice-osdi14.pdf

Regards,
Thanu
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm

Quoted 3 lines

You're missing the point. You can't take applications that don't know how to deal with torn sectors and put them on a block device that does not provide power fail write atomicity of a single sector.

Very few applications actually care about atomic sector writes.

IOWs, you've just pointed to an application that demonstrates pmem-safe behaviour - just configure the database files with "file:somefile.db?psow=0" and it will assume that individual sector writes can be torn, and it will always recover.

Hence I'm not sure exactly what point you are trying to make with this example.

Quoted 8 lines · Jeff Moyer

But, it seems plausible to me that no matter how well you optimize your msync implementation, it will still be more expensive than an application that doesn't call msync at all. This obviously depends on how the application is using the programming model, among other things. I agree that we would need real data to back this up. However, I don't see any reason to preclude such an implementation, or to leave it as a last resort. I think it should be part of our planning process if it's reasonably feasible.

Essentially I see this situation/request as conceptually the same as O_DIRECT for read/write - O_DIRECT bypasses the kernel dirty range tracking and, as such, has nasty cache coherency issues when you mix it with buffered IO. Nor does it play well with mmap, it has different semantics for every filesystem and the kernel code has been optimised to the point of fragility.

And, of course, O_DIRECT requires applications to do exactly the right things to extract performance gains and maintain data integrity. If they get it right, they will be faster than using the page cache, but we know that applications often get it very wrong. And even when they get it right, data corruption can still occur because some thrid party accessed file in a different manner (e.g. a backup) and triggered one of the known, fundamentally unfixable coherency problems.

However, despite the fact we are stuck with O_DIRECT and it's deranged monkeys (which I am one of), we should not be ignoring the problems that bypassing the kernel infrastructure has caused us and continues to cause us. As such, we really need to think hard about whether we should be repeating the development of such a bypass feature. If we do, we stand a very good chance of ending up in the same place - a bunch of code that does not play well with others, and a nightmare to test because it's expected to work and not corrupt data...

We should try very hard not to repeat the biggest mistake O_DIRECT
made: we need to define and document exactly what behaviour we guarantee, how it works and exaclty what responsisbilities the kernel and userspace have in *great detail* /before/ we add the mechanism to the kernel.

Think it through carefully - API changes and semantics are forever. We don't want to add something that in a couple of years we are wishing we never added....

Quoted 1 line · Thanumalayan Sankaranarayana Pillai

On Thu, Feb 25, 2016 at 10:02 PM, Dan Williams <dan.j.williams <at>

Quoted 8 lines

Quoted 8 lines

[ adding Thanu ]

Quoted 6 lines

Very few applications actually care about atomic sector writes. Databases are probably the only class of application that really do care about both single sector and multi-sector atomic write behaviour, and many of them can be configured to assume single sector writes can be torn.

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Torn user data writes have always been possible, and so pmem does not introduce any new semantics that applications have to handle.

I know about BTT and DAX only at a conceptual level and hence do not

Quoted 1 line

this mailing thread fully. But I can provide examples of important

Quoted 4 lines

expecting atomicity at a 512B or a smaller granularity. Here is a list:

(1) LMDB [1] that Dan mentioned, which expects "linear writes" (i.e., don't need atomicity, but need the first byte to be written before the second

Quoted 5 lines

(2) PostgreSQL expects atomicity [2]

(3) SQLite depends on linear writes [3] (we were unable to find these dependencies during our testing, however). Also, PSOW in SQLite is not

Quoted 4 lines

to this discussion as I understand it; PSOW deals with corruption of data *around* the actual written bytes.

(4) We found that ZooKeeper depends on atomicity during our testing, but

Quoted 1 line

not contact the ZooKeeper developers about this. Some details in our

Quoted 5 lines

It is tempting to assume that applications do not use the concept of disk sectors and deal with only file-system blocks (which are not atomic in practice), and take measures to deal with the non-atomic file-system blocks. But, in reality, applications seem to assume that 512B (more or less)

Quoted 2 lines

are atomic or linear, and build their consistency mechanisms around that.

This all discussion is a shock to me. where were these guys hiding, under

In the NFS world you can get not torn sectors but torn words. You may have reorder of writes, you may have data holes the all deal. Until you get back a successful sync nothing is guarantied. It is not only a client crash but also a network breach, and so on. So you never know what can happen.

So are you saying all these applications do not run on NFS?

Thanks
Boaz

Quoted 4 lines

[1] http://www.openldap.org/list~s/openldap-devel/201410/msg00004.html
[2] http://www.postgresql.org/docs/9.5/static/wal-internals.html , "To deal with the case where pg_control is corrupt" ...
[3] https://www.sqlite.org/atomiccommit.html , "SQLite does always

Quoted 10 lines

a sector write is linear" ...
[4] http://research.cs.wisc.edu/wind/Publications/alice-osdi14.pdf

Regards,
Thanu
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm <at> lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Hi all

Recent DAX code fixed the cl_flushing ie durability of mmap access of direct persistent-memory from applications. It uses the radix-tree per inode to track the indexes of a file that where page-faulted for write. Then at m/fsync time it would cl_flush these pages and clean the radix-tree, for the next round.

Sigh, that is life, for legacy applications this is the price we must pay. But for NV aware applications like nvml library, we pay extra extra price, even if we do not actually call m/fsync eventually. For these applications these extra resources and especially the extra radix locking per page-fault, costs a lot, like x3 a lot.

What we propose here is a way for those applications to enjoy the boost and still not sacrifice any correctness of legacy applications. Any concurrent access from legacy apps vs nv-aware apps even to the same file / same page, will work correctly.

We do that by defining a new MMAP flag that is set by the nv-aware app. this flag is carried by the VMA. In the dax code we bypass any radix handling of the page if this flag is set. Those pages accessed *without* this flag will be added to the radix-tree, those with will not. At m/fsync time if the radix tree is then empty nothing will happen.

Quoted 20 lines · Boaz Harrosh

Hi all

Recent DAX code fixed the cl_flushing ie durability of mmap access of direct persistent-memory from applications. It uses the radix-tree per inode to track the indexes of a file that where page-faulted for write. Then at m/fsync time it would cl_flush these pages and clean the radix-tree, for the next round.

Sigh, that is life, for legacy applications this is the price we must pay. But for NV aware applications like nvml library, we pay extra extra price, even if we do not actually call m/fsync eventually. For these applications these extra resources and especially the extra radix locking per page-fault, costs a lot, like x3 a lot.

What we propose here is a way for those applications to enjoy the boost and still not sacrifice any correctness of legacy applications. Any concurrent access from legacy apps vs nv-aware apps even to the same file / same page, will work correctly.

Quoted 7 lines

We do that by defining a new MMAP flag that is set by the nv-aware app. this flag is carried by the VMA. In the dax code we bypass any radix handling of the page if this flag is set. Those pages accessed *without*
this flag will be added to the radix-tree, those with will not. At m/fsync time if the radix tree is then empty nothing will happen.

I'm a little late to the party, but let me offer a variant that might be considerably safer:

Add a flag MAP_DAX_WRITETHROUGH (name could be debated -- MAP_DAX_FASTFLUSH might be more architecture-neutral, but I'm only familiar with the x86 semantics).

MAP_DAX_WRITETHROUGH does whatever is needed to ensure that writing through the mapping and then calling fsync is both safe and fast. On x86, it would (surprise, surprise!) map the pages writethrough and skip adding them to the radix tree. fsync makes sure to do sfence before pcommit.

This is totally safe. You *can't* abuse this to cause fsync to leave non-persistent dirty cached data anywhere.

It makes sufficiently DAX-aware applications very fast. Reads are unaffected, and non-temporal writes should be the same speed as they are under any other circumstances.

It makes applications that set it blindly very slow. Applications that use standard writes (i.e. plain stores that are neither fast string operations nor explicit non-temporal writes) will suffer. But they'll still work correctly.

Applications that want a WB mapping with manually-managed persistence can still do it, but fsync will be slow. Adding an fmetadatasync() for their benefit might be a decent idea, but it would just be icing on the cake.

Unlike with MAP_DAX_AWARE, there's no issue with malicious users who map the thing with the wrong flag, write, call fsync, and snicker because now the other applications might read data and be surprised that the data they just read isn't persistent even if they subsequently call fsync.

There would be details to be hashed out in case a page is mapped normally and with MAP_DAX_WRITETHROUGH in separate mappings.

Quoted 57 lines · Andy Lutomirski

Quoted 20 lines · Boaz Harrosh

Hi all

Recent DAX code fixed the cl_flushing ie durability of mmap access of direct persistent-memory from applications. It uses the radix-tree per inode to track the indexes of a file that where page-faulted for write. Then at m/fsync time it would cl_flush these pages and clean the radix-tree, for the next round.

Sigh, that is life, for legacy applications this is the price we must pay. But for NV aware applications like nvml library, we pay extra extra price, even if we do not actually call m/fsync eventually. For these applications these extra resources and especially the extra radix locking per page-fault, costs a lot, like x3 a lot.

What we propose here is a way for those applications to enjoy the boost and still not sacrifice any correctness of legacy applications. Any concurrent access from legacy apps vs nv-aware apps even to the same file / same page, will work correctly.

Quoted 7 lines

We do that by defining a new MMAP flag that is set by the nv-aware app. this flag is carried by the VMA. In the dax code we bypass any radix handling of the page if this flag is set. Those pages accessed *without*
this flag will be added to the radix-tree, those with will not. At m/fsync time if the radix tree is then empty nothing will happen.

I'm a little late to the party, but let me offer a variant that might be considerably safer:

Add a flag MAP_DAX_WRITETHROUGH (name could be debated -- MAP_DAX_FASTFLUSH might be more architecture-neutral, but I'm only familiar with the x86 semantics).

MAP_DAX_WRITETHROUGH does whatever is needed to ensure that writing through the mapping and then calling fsync is both safe and fast. On x86, it would (surprise, surprise!) map the pages writethrough and skip adding them to the radix tree. fsync makes sure to do sfence before pcommit.

This is totally safe. You *can't* abuse this to cause fsync to leave non-persistent dirty cached data anywhere.

It makes sufficiently DAX-aware applications very fast. Reads are unaffected, and non-temporal writes should be the same speed as they are under any other circumstances.

It makes applications that set it blindly very slow. Applications that use standard writes (i.e. plain stores that are neither fast string operations nor explicit non-temporal writes) will suffer. But they'll still work correctly.

Applications that want a WB mapping with manually-managed persistence can still do it, but fsync will be slow. Adding an fmetadatasync() for their benefit might be a decent idea, but it would just be icing on the cake.

Quoted 8 lines

Unlike with MAP_DAX_AWARE, there's no issue with malicious users who map the thing with the wrong flag, write, call fsync, and snicker because now the other applications might read data and be surprised that the data they just read isn't persistent even if they subsequently call fsync.

There would be details to be hashed out in case a page is mapped normally and with MAP_DAX_WRITETHROUGH in separate mappings.

Interesting...

The mixed mapping problem is made slightly more difficult by the fact that we add persistent memory to the direct-map when allocating struct page, but probably not insurmountable. Also, this still has the syscall overhead that a MAP_SYNC semantic eliminates, but we need to collect numbers to see if that matters.

However, chatting with Andy R. about the NVML use case, the library alternates between streaming non-temporal writes and byte-accesses + clwb(). The byte accesses get slower with a write-through mapping. So, performance data is needed all around to see where these options land.