11:05 a.m.
On 02/22/2016 12:03 AM, Dan Williams wrote:
On Sun, Feb 21, 2016 at 1:23 PM, Boaz Harrosh
<boaz(a)plexistor.com> wrote:
<>
> 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.
Warning rant: Rrrr the theoretical pcommit. We have built mountains
on a none existing CPU. Show me a pcomit already.
But yes pcommit changes nothing.
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.
But we are not breaking any current POSIX guaranties. You are thinking
memory, but this is POSIX filesystem semantics. This is all up to the
application.
Consider a regular page-cached FS, and your above two applications,
(Which BTW do not exist exactly because). Both are doing a write not
to a cacheline to a page even:
App 1 app2
- write block X ...
- sync write block X
- POWER OFF
There is no guaranty that app 1 version is what will be read
after mount. Any random amount of app2 changes can be seen.
In fact even while the pages are in DMA they can change.
All that is guarantied is that the page will be marked dirty
because app 2 dirty it even though app 1 submitted it to be
cleaned.
And is what we have. If app 2 is pmem-unaware the page is added
to the radix tree, come sync time it will cl_flush.
In Any which case after the write storms end, and a final
sync is preformed we should have an image of the very last
writes. This is POSIX. And this is kept here.
So no no need for "shared mapping have the same awareness"
[BTW: coming from the NFS world all this is one big lough
because there we don't even have a read concurrent write
guaranty let alone a write vs write guaranty.]
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.
Yes good idea, will do.
Shalom
Boaz