All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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: link
Be 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.