On 02/22/2016 12:03 AM, Dan Williams wrote: > On Sun, Feb 21, 2016 at 1:23 PM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>