On Wed, Oct 18, 2017 at 08:51:37AM -0700, Dan Williams wrote:
> This use case is not "Persistent Memory". Persistent Memory is
> something you can map and make persistent with CPU instructions.
> Anything that requires a driver call is device driver managed "Shared
> Memory".
How is this any diffe
On Wed, Oct 18, 2017 at 08:51:37AM -0700, Dan Williams wrote:
> On Wed, Oct 18, 2017 at 6:03 AM, Stefan Hajnoczi wrote:
> > On Tue, Oct 17, 2017 at 04:30:41AM -0400, Pankaj Gupta wrote:
> >>
> >> > > Are you saying do it as existing i.e ACPI pmem like interface?
> >> > > The reason we have created
dax_pmd_insert_mapping() has only one callsite and we will need to
further fine tune what it does for synchronous faults. Just inline it
into the callsite so that we don't have to pass awkward bools around.
Reviewed-by: Christoph Hellwig
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
---
fs
Define new MAP_SYNC flag and corresponding VMA VM_SYNC flag. As the
MAP_SYNC flag is not part of LEGACY_MAP_MASK, currently it will be
refused by all MAP_SHARED_VALIDATE map attempts and silently ignored for
everything else.
Reviewed-by: Ross Zwisler
Reviewed-by: Christoph Hellwig
Signed-off-by:
Implement a function that filesystems can call to finish handling of
synchronous page faults. It takes care of syncing appropriare file range
and insertion of page table entry.
Reviewed-by: Ross Zwisler
Reviewed-by: Christoph Hellwig
Signed-off-by: Jan Kara
---
fs/dax.c |
From: Christoph Hellwig
Return IOMAP_F_DIRTY from xfs_file_iomap_begin() when asked to prepare
blocks for writing and the inode is pinned, and has dirty fields other
than the timestamps. In __xfs_filemap_fault() we then detect this case
and call dax_finish_sync_fault() to make sure all metadata
Add missing argument description.
Reviewed-by: Christoph Hellwig
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
---
fs/dax.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/dax.c b/fs/dax.c
index 675fab8ec41f..5214ed9ba508 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -14
Factor out code to get pfn out of iomap that is shared between PTE and
PMD fault path.
Reviewed-by: Christoph Hellwig
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
---
fs/dax.c | 83 +---
1 file changed, 43 insertions(+), 40 delet
For synchronous page fault dax_iomap_fault() will need to return PFN
which will then need to be inserted into page tables after fsync()
completes. Add necessary parameter to dax_iomap_fault().
Reviewed-by: Christoph Hellwig
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
---
fs/dax.c
From: Dan Williams
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC need a mechanism to
define new behavior that is known to fail on older kernels without the
support. Define a new MAP_SHARED_VALIDATE flag pattern that is
guar
Currently we dirty radix tree entry whenever dax_insert_mapping_entry()
gets called for a write fault. With synchronous page faults we would
like to insert clean radix tree entry and dirty it only once we call
fdatasync() and update page tables to save some unnecessary cache
flushing. Add 'dirty' a
There are already two users and more are coming.
Reviewed-by: Christoph Hellwig
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
---
fs/dax.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 116eef8d6c69..c09465884bbe 100644
--- a/fs/dax.c
+++
It is unused.
Reviewed-by: Ross Zwisler
Reviewed-by: Christoph Hellwig
Signed-off-by: Jan Kara
---
include/linux/mm.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 065d99deb847..ca72b67153d5 100644
--- a/include/linux/mm.h
+++ b/include/linu
Add a flag to iomap interface informing the caller that inode needs
fdstasync(2) for returned extent to become persistent and use it in DAX
fault code so that we don't map such extents into page tables
immediately. Instead we propagate the information that fdatasync(2) is
necessary from dax_iomap_f
Hello,
here is the fourth version of my patches to implement synchronous page faults
for DAX mappings to make flushing of DAX mappings possible from userspace so
that they can be flushed on finer than page granularity and also avoid the
overhead of a syscall.
We use a new mmap flag MAP_SYNC to in
We return IOMAP_F_DIRTY flag from ext4_iomap_begin() when asked to
prepare blocks for writing and the inode has some uncommitted metadata
changes. In the fault handler ext4_dax_fault() we then detect this case
(through VM_FAULT_NEEDDSYNC return value) and call helper
dax_finish_sync_fault() to flus
If transaction starting fails, just bail out of the function immediately
instead of checking for that condition throughout the function.
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
---
fs/ext4/file.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/ext4
Signed-off-by: Jan Kara
---
man2/mmap.2 | 30 ++
1 file changed, 30 insertions(+)
diff --git a/man2/mmap.2 b/man2/mmap.2
index 47c3148653be..598ff0c64f7f 100644
--- a/man2/mmap.2
+++ b/man2/mmap.2
@@ -125,6 +125,21 @@ are carried through to the underlying file.
to th
There are already two users and more are coming.
Reviewed-by: Christoph Hellwig
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
---
fs/dax.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index c09465884bbe..5ea71381dba0 100644
--- a/fs/dax.c
+++
dax_insert_mapping() has only one callsite and we will need to further
fine tune what it does for synchronous faults. Just inline it into the
callsite so that we don't have to pass awkward bools around.
Reviewed-by: Christoph Hellwig
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
---
fs/dax
> +#define XFS_MAP_SUPPORTED (LEGACY_MAP_MASK | MAP_SYNC)
I'd kill this define. Also is there any good reason that we have
to add LEGACY_MAP_MASK instead of assuming it's supported in the
core?
> #endif
> .mmap = xfs_file_mmap,
> + .mmap_supported_flags = XFS_MAP_SUPPORTED
dax_insert_mapping() has lots of arguments and a lot of them is actuall
duplicated by passing vm_fault structure as well. Change the function to
take the same arguments as dax_pmd_insert_mapping().
Reviewed-by: Ross Zwisler
Reviewed-by: Christoph Hellwig
Signed-off-by: Jan Kara
---
fs/dax.c |
The original message was received at Thu, 19 Oct 2017 21:56:53 +0800
from lists.01.org [111.41.225.161]
- The following addresses had permanent fatal errors -
- Transcript of session follows -
while talking to lists.01.org.:
>>> MAIL From:"Bounced mail"
<<< 501 "Bounced mail"
On Thu, Oct 19, 2017 at 5:58 AM, Jan Kara wrote:
>
> From: Dan Williams
>
> The mmap(2) syscall suffers from the ABI anti-pattern of not validating
> unknown flags. However, proposals like MAP_SYNC need a mechanism to
> define new behavior that is known to fail on older kernels without the
> supp
Hi, Dan,
Referring to
https://patchwork.kernel.org/project/linux-nvdimm/list/?page=6
[RFC,2/2] mm, fs: daxfile, an interface for byte-addressable updates
to pmem
I'm unable to find the patch in Linux upstream kernel, and am wondering if
there has been a change of plan for providing supp
On Thu, Oct 19, 2017 at 1:01 AM, Christoph Hellwig wrote:
> On Wed, Oct 18, 2017 at 08:51:37AM -0700, Dan Williams wrote:
>> This use case is not "Persistent Memory". Persistent Memory is
>> something you can map and make persistent with CPU instructions.
>> Anything that requires a driver call is
以下课程上海，深圳，即将主办，席位预定中！
全能型车间主任实战技能
企业安全、环境（EHS）系统化实战训练
详情 请 阅读 附 件 内 容
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
jane@oracle.com writes:
> Hi, Dan,
>
> Referring to
>
> https://patchwork.kernel.org/project/linux-nvdimm/list/?page=6
>
> [RFC,2/2] mm, fs: daxfile, an interface for byte-addressable updates
> to pmem
>
> I'm unable to find the patch in Linux upstream kernel, and am wondering if
> there has b
On Thu, Oct 19, 2017 at 2:41 PM, Jeff Moyer wrote:
> jane@oracle.com writes:
>
>> Hi, Dan,
>>
>> Referring to
>>
>> https://patchwork.kernel.org/project/linux-nvdimm/list/?page=6
>>
>> [RFC,2/2] mm, fs: daxfile, an interface for byte-addressable updates
>> to pmem
>>
>> I'm unable to find the
On 10/19/2017 03:33 PM, Dan Williams wrote:
On Thu, Oct 19, 2017 at 2:41 PM, Jeff Moyer wrote:
jane@oracle.com writes:
Hi, Dan,
Referring to
https://patchwork.kernel.org/project/linux-nvdimm/list/?page=6
[RFC,2/2] mm, fs: daxfile, an interface for byte-addressable updates
to pmem
I'm
On Thu, Oct 19, 2017 at 4:59 PM, wrote:
[..]
> Thank you both for the clarification!
> Is there documents that elaborate the new resolve in detail?
This might answer some of your questions: https://lwn.net/Articles/731706/
___
Linux-nvdimm mailing list
On Wed, Oct 18, 2017 at 11:21 AM, Ross Zwisler
wrote:
> Fix this build warning:
>
> warning: 'phys' may be used uninitialized in this function
> [-Wuninitialized]
>
> As reported here:
>
> https://lkml.org/lkml/2017/10/16/152
> http://kisskb.ellerman.id.au/kisskb/buildresult/13181373/log/
>
> Sign
This flag is deprecated in favor of the vma_is_dax() check in
transparent_hugepage_enabled() added in commit baabda261424 "mm: always
enable thp for dax mappings"
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Ross Zwisler
Reviewed-by: Jan Kara
Signed-off-by: Dan Williams
---
drivers/dax/device.c
Changes since v2 [1]:
* Add 'dax: handle truncate of dma-busy pages' which builds on the
removal of page-less dax to fix a latent bug handling dma vs truncate.
* Disable get_user_pages_fast() for dax
* Disable RDMA memory registrations against filesystem-DAX mappings for
non-ODP (On Demand Pagi
Now that dax_flush() is no longer a driver callback (commit c3ca015fab6d
"dax: remove the pmem_dax_ops->flush abstraction"), stop requiring the
dax_read_lock() to be held and the device to be alive. This is in
preparation for switching filesystem-dax to store pfns instead of
sectors in the radix.
Before we add another failure reason, quiet the existing log messages.
Leave it to the caller to decide if bdev_dax_supported() failures are
errors worth emitting to the log.
Reported-by: Jeff Moyer
Signed-off-by: Dan Williams
---
drivers/dax/super.c |8
1 file changed, 4 insertion
VM_MIXEDMAP is used by dax to direct mm paths like vm_normal_page() that
the memory page it is dealing with is not typical memory from the linear
map. The get_user_pages_fast() path, since it does not resolve the vma,
is already using {pte,pmd}_devmap() as a stand-in for VM_MIXEDMAP, so we
use that
In preparation for solving the dax-dma vs truncate race, disable
get_user_pages_fast(). The race fix relies on the vma being available.
We can still support get_user_pages_fast() for 1GB (pud) 'devmap'
mappings since those are only implemented for device-dax, everything
else needs the vma and the
If a dax buffer from a device that does not map pages is passed to
read(2) or write(2) as a target for direct-I/O it triggers SIGBUS. If
gdb attempts to examine the contents of a dax buffer from a device that
does not map pages it triggers SIGBUS. If fork(2) is called on a process
with a dax mappin
In support of testing truncate colliding with dma add a mechanism that
delays the completion of block I/O requests by a programmable number of
seconds. This allows a truncate operation to be issued while page
references are held for direct-I/O.
Signed-off-by: Dan Williams
---
tools/testing/nvdim
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow RDMA to create long standing memory registrations
against filesytem-dax vmas. Device-dax vmas do not have this problem and
are explicitly allowed.
This is temporary until a "memory registration with layout-leas
Catch cases where truncate encounters pages that are still under active
dma. This warning is a canary for potential data corruption as truncated
blocks could be allocated to a new file while the device is still
perform i/o.
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Matthew Wilcox
C
get_user_pages() pins file backed memory pages for access by dma
devices. However, it only pins the memory pages not the page-to-file
offset association. If a file is truncated the pages are mapped out of
the file and dma may continue indefinitely into a page that is owned by
a device driver. This
In preparation for examining the busy state of dax pages in the truncate
path, switch from sectors to pfns in the radix.
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Matthew Wilcox
Cc: Ross Zwisler
Signed-off-by: Dan Williams
---
fs/dax.c | 75 +++-
Before xfs can be sure that it is safe to truncate it needs to hold
XFS_MMAP_LOCK_EXCL and flush any FL_ALLOCATED leases. Introduce
xfs_break_allocated() modeled after xfs_break_layouts() for use in the
file space deletion path.
We also use a new address_space_operation for the fs/dax core to
coo
Commit 128a37852234 "fs: fix data races on inode->i_flctx" converted
checks of inode->i_flctx to use smp_load_acquire(), but it did not
convert break_layout(). smp_load_acquire() includes a READ_ONCE(). There
should be no functional difference since __break_lease repeats the
sequence, but this is a
Currently dm-log-writes supports writing filesystem data via BIOs, and
writing internal metadata from a flat buffer via write_metadata().
For DAX writes, though, we won't have a BIO, but will instead have an
iterator that we'll want to use to fill a flat data buffer.
So, create write_inline_data(
Now that we have the ability log filesystem writes using a flat buffer, add
support for DAX. Unfortunately we can't easily track data that has been
written via mmap() now that the dax_flush() abstraction was removed by this
commit:
commit c3ca015fab6d ("dax: remove the pmem_dax_ops->flush abstrac
Add a test that exercises DAX's new MAP_SYNC flag.
This test creates a file and writes to it via an mmap(), but never syncs
via fsync/msync. This process is tracked via dm-log-writes, then replayed.
If MAP_SYNC is working the dm-log-writes replay will show the test file
with the same size that w
如何解决【常见问题】
l 业绩压力大，但要提升业绩又觉得无从下手，怎么办？
l 报价后客户就没有回应了，怎么办？
l 客户拿着我们的报价与别人比，说我们的价格贵，怎么办？
l 与客户联络一段时间了，但客户一直不下单，怎么办？
l 提供样品给客户测试后，客户就不理我们了，怎么办？
l 开发陌生客户时，有没有好的方法减少电话或邮件的拒绝率？
l 收到客户的询盘后，认真分析过客户的需求并回复了，但客户反馈的很少，怎么办？
l 如何把老客户的满意度转化为销量？
详细 内容 参阅 附件 大纲
杭瘩
2017-10-20/14:08:34
On Fri, Oct 20, 2017 at 8:29 AM, Ross Zwisler
wrote:
> Add a test that exercises DAX's new MAP_SYNC flag.
>
> This test creates a file and writes to it via an mmap(), but never syncs
> via fsync/msync. This process is tracked via dm-log-writes, then replayed.
>
> If MAP_SYNC is working the dm-log
51 matches
Mail list logo
