Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

From: Dan Williams [mailto:dan.j.willi...@intel.com] > A couple weeks back, in the course of reviewing the memcpy_nocache() > proposal from Brian, Linus subtly suggested that the pmem specific > memcpy_to_pmem() routine be moved to be implemented at the driver > level [1]: Of course, there may

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

From: Christoph Hellwig [mailto:h...@lst.de] > On Sat, Jan 21, 2017 at 04:28:52PM +, Matthew Wilcox wrote: > > Of course, there may not be a backing device either! > > s/backing device/block device/ ? If so fully agreed. I like the dax_ops > scheme, but we should go all the way and detangle

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

From: Christoph Hellwig [mailto:h...@lst.de] > On Sun, Jan 22, 2017 at 06:39:28PM +, Matthew Wilcox wrote: > > Two guests on the same physical machine (or a guest and a host) have access > > to the same set of physical addresses. This might be an NV-DIMM, or it > > might > > just be DRAM

[dm-devel] [PATCH] dm bio prison: use rb_entry()

To make the code clearer, use rb_entry() instead of container_of() to deal with rbtree. Signed-off-by: Geliang Tang --- drivers/md/dm-bio-prison.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-bio-prison.c b/drivers/md/dm-bio-prison.c

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

From: Christoph Hellwig [mailto:h...@lst.de] > On Sun, Jan 22, 2017 at 06:19:24PM +, Matthew Wilcox wrote: > > No, I mean a network filesystem like 9p or cifs or nfs. If the memcpy > > is supposed to be performed by the backing device > > struct backing_dev has no relation to the DAX code.

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sun, Jan 22, 2017 at 10:37 PM, Matthew Wilcox wrote: > From: Christoph Hellwig [mailto:h...@lst.de] >> On Sun, Jan 22, 2017 at 06:39:28PM +, Matthew Wilcox wrote: >> > Two guests on the same physical machine (or a guest and a host) have access >> > to the same set

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sun, Jan 22, 2017 at 06:39:28PM +, Matthew Wilcox wrote: > Two guests on the same physical machine (or a guest and a host) have access > to the same set of physical addresses. This might be an NV-DIMM, or it might > just be DRAM (for the purposes of reducing guest overhead). The network

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sun, Jan 22, 2017 at 06:19:24PM +, Matthew Wilcox wrote: > No, I mean a network filesystem like 9p or cifs or nfs. If the memcpy > is supposed to be performed by the backing device struct backing_dev has no relation to the DAX code. Even more so what's the point of doing a DAXish memcpy

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sat, Jan 21, 2017 at 9:52 AM, Christoph Hellwig wrote: > On Sat, Jan 21, 2017 at 04:28:52PM +, Matthew Wilcox wrote: >> Of course, there may not be a backing device either! > > s/backing device/block device/ ? If so fully agreed. I like the dax_ops > scheme, but we should go

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sun, Jan 22, 2017 at 03:43:09PM +, Matthew Wilcox wrote: > In the case of a network filesystem being used to communicate with > a different VM on the same physical machine, there is no backing > device, just a network protocol. Again, do you mean block device? For a filesystem that does