From: Boaz Harrosh <boazh@netapp.com> To: Dan Williams <dan.j.williams@intel.com> Cc: Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>, linux-nvdimm <linux-nvdimm@lists.01.org>, Dave Chinner <david@fromorbit.com>, linux-xfs@vger.kernel.org, Andy Lutomirski <luto@kernel.org>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>, Amit Golander <amitg@netapp.com> Subject: Re: [RFC PATCH 0/7] dax, ext4: Synchronous page faults Date: Tue, 15 Aug 2017 12:44:40 +0300 [thread overview] Message-ID: <13c329d6-ba79-be04-28b1-4d845271533e@netapp.com> (raw) In-Reply-To: <2ac0880f-d661-2493-0f80-1b930a8b858b@netapp.com> On 15/08/17 12:06, Boaz Harrosh wrote: > On 14/08/17 19:03, Dan Williams wrote: >> On Mon, Aug 14, 2017 at 7:04 AM, Boaz Harrosh <boazh@netapp.com> wrote: >>> >>> Thank you Jan, I'm patiently waiting for this MAP_SYNC flag since I asked for >>> it in 2014. I'm so glad its time is finally do. >>> > > <> > >>> 4] Once we have this flag. And properly implemented at least in one FS >>> and optionally in /dev/pmemX we no longer have any justification for >>> /dev/daxX and it can die a slow and happy death. >> >> I'm all for replacing /dev/dax with filesystem equivalent >> functionality, but I don't think MAP_SYNC gets us fully there. That's >> what the MAP_DIRECT proposal [1] is meant to address. >> > > OK This is true. Could you please summarise for us the exact semantics of both > proposed flags? > > That said I think the big difference is the movability of physical blocks > underneath the mmap mapping. Now for swap files that is a problem. because > of the deadlocks that can happen with memory needed if blocks start moving. > But for an application like nvml? why does it care. Why can't an nvml image file > not be cloned and COWed underneath the NVM application transparently. > OK Sorry didn't do my homework. Struck this out, it is all about RDMA and friends from an "immutable" file. I'll go dig into this now. Thanks Boaz > Sorry for being slow but I don't see why you need MAP_DIRECT from user-mode > If you have MAP_SYNC. Please advise > > (not that the immutable patchset is not a very needed fixing) > >> [1]: https://lkml.org/lkml/2017/8/13/160 >> > > Thanks > Boaz >
WARNING: multiple messages have this Message-ID (diff)
From: Boaz Harrosh <boazh@netapp.com> To: Dan Williams <dan.j.williams@intel.com> Cc: Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>, linux-nvdimm <linux-nvdimm@lists.01.org>, Dave Chinner <david@fromorbit.com>, <linux-xfs@vger.kernel.org>, Andy Lutomirski <luto@kernel.org>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>, Amit Golander <amitg@netapp.com> Subject: Re: [RFC PATCH 0/7] dax, ext4: Synchronous page faults Date: Tue, 15 Aug 2017 12:44:40 +0300 [thread overview] Message-ID: <13c329d6-ba79-be04-28b1-4d845271533e@netapp.com> (raw) In-Reply-To: <2ac0880f-d661-2493-0f80-1b930a8b858b@netapp.com> On 15/08/17 12:06, Boaz Harrosh wrote: > On 14/08/17 19:03, Dan Williams wrote: >> On Mon, Aug 14, 2017 at 7:04 AM, Boaz Harrosh <boazh@netapp.com> wrote: >>> >>> Thank you Jan, I'm patiently waiting for this MAP_SYNC flag since I asked for >>> it in 2014. I'm so glad its time is finally do. >>> > > <> > >>> 4] Once we have this flag. And properly implemented at least in one FS >>> and optionally in /dev/pmemX we no longer have any justification for >>> /dev/daxX and it can die a slow and happy death. >> >> I'm all for replacing /dev/dax with filesystem equivalent >> functionality, but I don't think MAP_SYNC gets us fully there. That's >> what the MAP_DIRECT proposal [1] is meant to address. >> > > OK This is true. Could you please summarise for us the exact semantics of both > proposed flags? > > That said I think the big difference is the movability of physical blocks > underneath the mmap mapping. Now for swap files that is a problem. because > of the deadlocks that can happen with memory needed if blocks start moving. > But for an application like nvml? why does it care. Why can't an nvml image file > not be cloned and COWed underneath the NVM application transparently. > OK Sorry didn't do my homework. Struck this out, it is all about RDMA and friends from an "immutable" file. I'll go dig into this now. Thanks Boaz > Sorry for being slow but I don't see why you need MAP_DIRECT from user-mode > If you have MAP_SYNC. Please advise > > (not that the immutable patchset is not a very needed fixing) > >> [1]: https://lkml.org/lkml/2017/8/13/160 >> > > Thanks > Boaz >
next prev parent reply other threads:[~2017-08-15 9:44 UTC|newest] Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-27 13:12 [RFC PATCH 0/7] dax, ext4: Synchronous page faults Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` [PATCH 1/7] mm: Remove VM_FAULT_HWPOISON_LARGE_MASK Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 21:57 ` Ross Zwisler 2017-07-27 21:57 ` Ross Zwisler 2017-07-27 21:57 ` Ross Zwisler 2017-08-01 10:52 ` Christoph Hellwig 2017-08-01 10:52 ` Christoph Hellwig 2017-08-01 10:52 ` Christoph Hellwig 2017-07-27 13:12 ` [PATCH 2/7] dax: Add sync argument to dax_iomap_fault() Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 22:06 ` Ross Zwisler 2017-07-27 22:06 ` Ross Zwisler 2017-07-27 22:06 ` Ross Zwisler 2017-07-28 9:40 ` Jan Kara 2017-07-28 9:40 ` Jan Kara 2017-07-27 13:12 ` [PATCH 3/7] dax: Simplify arguments of dax_insert_mapping() Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 22:09 ` Ross Zwisler 2017-07-27 22:09 ` Ross Zwisler 2017-07-27 22:09 ` Ross Zwisler 2017-08-01 10:54 ` Christoph Hellwig 2017-08-01 10:54 ` Christoph Hellwig 2017-08-01 10:54 ` Christoph Hellwig 2017-07-27 13:12 ` [PATCH 4/7] dax: Make dax_insert_mapping() return VM_FAULT_ state Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 22:22 ` Ross Zwisler 2017-07-27 22:22 ` Ross Zwisler 2017-07-28 9:43 ` Jan Kara 2017-07-28 9:43 ` Jan Kara 2017-07-27 13:12 ` [PATCH 5/7] dax, iomap: Add support for synchronous faults Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 22:42 ` Ross Zwisler 2017-07-27 22:42 ` Ross Zwisler 2017-08-01 10:56 ` Christoph Hellwig 2017-08-01 10:56 ` Christoph Hellwig 2017-08-01 10:56 ` Christoph Hellwig 2017-07-27 13:12 ` [PATCH 6/7] dax: Implement dax_pfn_mkwrite() Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 22:53 ` Ross Zwisler 2017-07-27 22:53 ` Ross Zwisler 2017-07-27 22:53 ` Ross Zwisler 2017-07-27 23:04 ` Ross Zwisler 2017-07-27 23:04 ` Ross Zwisler 2017-07-28 10:37 ` Jan Kara 2017-07-28 10:37 ` Jan Kara 2017-07-28 10:37 ` Jan Kara 2017-07-27 13:12 ` [PATCH 7/7] ext4: Support for synchronous DAX faults Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 13:12 ` Jan Kara 2017-07-27 22:57 ` Ross Zwisler 2017-07-27 22:57 ` Ross Zwisler 2017-07-27 14:09 ` [RFC PATCH 0/7] dax, ext4: Synchronous page faults Jeff Moyer 2017-07-27 14:09 ` Jeff Moyer 2017-07-27 14:09 ` Jeff Moyer 2017-07-27 21:57 ` Ross Zwisler 2017-07-27 21:57 ` Ross Zwisler 2017-07-28 2:05 ` Andy Lutomirski 2017-07-28 2:05 ` Andy Lutomirski 2017-07-28 9:38 ` Jan Kara 2017-07-28 9:38 ` Jan Kara 2017-07-28 9:38 ` Jan Kara 2017-08-01 11:02 ` Christoph Hellwig 2017-08-01 11:02 ` Christoph Hellwig 2017-08-01 11:26 ` Jan Kara 2017-08-01 11:26 ` Jan Kara 2017-08-01 11:26 ` Jan Kara 2017-08-08 0:24 ` Dan Williams 2017-08-08 0:24 ` Dan Williams 2017-08-11 10:03 ` Christoph Hellwig 2017-08-11 10:03 ` Christoph Hellwig 2017-08-11 10:03 ` Christoph Hellwig 2017-08-13 2:44 ` Dan Williams 2017-08-13 2:44 ` Dan Williams 2017-08-13 2:44 ` Dan Williams 2017-08-13 9:25 ` Christoph Hellwig 2017-08-13 9:25 ` Christoph Hellwig 2017-08-13 17:08 ` Dan Williams 2017-08-13 17:08 ` Dan Williams 2017-08-14 8:30 ` Jan Kara 2017-08-14 8:30 ` Jan Kara 2017-08-14 14:04 ` Boaz Harrosh 2017-08-14 14:04 ` Boaz Harrosh 2017-08-14 16:03 ` Dan Williams 2017-08-14 16:03 ` Dan Williams 2017-08-15 9:06 ` Boaz Harrosh 2017-08-15 9:06 ` Boaz Harrosh 2017-08-15 9:44 ` Boaz Harrosh [this message] 2017-08-15 9:44 ` Boaz Harrosh 2017-08-21 19:57 ` Ross Zwisler 2017-08-21 19:57 ` Ross Zwisler 2017-08-21 19:57 ` Ross Zwisler 2017-08-17 16:08 ` Jan Kara 2017-08-17 16:08 ` Jan Kara 2017-08-01 10:52 ` Christoph Hellwig 2017-08-01 10:52 ` Christoph Hellwig 2017-08-01 10:52 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=13c329d6-ba79-be04-28b1-4d845271533e@netapp.com \ --to=boazh@netapp.com \ --cc=amitg@netapp.com \ --cc=dan.j.williams@intel.com \ --cc=david@fromorbit.com \ --cc=hch@infradead.org \ --cc=jack@suse.cz \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-nvdimm@lists.01.org \ --cc=linux-xfs@vger.kernel.org \ --cc=luto@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.