Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote: > On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote: > > Dan Williams and Christoph Hellwig have recently expressed doubt about > > whether the rw_page() interface made sense for synchronous memory drivers > > [1][2]. It's

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

[ adding Tim and Ying who have also been looking at swap optimization and rw_page interactions ] On Wed, Aug 2, 2017 at 5:13 PM, Minchan Kim wrote: > Hi Ross, > > On Wed, Aug 02, 2017 at 04:13:59PM -0600, Ross Zwisler wrote: >> On Fri, Jul 28, 2017 at 10:31:43AM -0700,

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

Hi Ross, On Wed, Aug 02, 2017 at 04:13:59PM -0600, Ross Zwisler wrote: > On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote: > > On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote: > > > Dan Williams and Christoph Hellwig have recently expressed doubt about > > > whether the

Delivery reports about your e-mail

The original message was received at Thu, 3 Aug 2017 08:12:38 +0800 from pmc-sierra.com [108.177.199.22] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.01.org.: >>> MAIL

Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

On 8/2/2017 2:41 PM, Dave Jiang wrote: > if (queue_mode == PMEM_Q_MQ) { > + chan = dma_find_channel(DMA_MEMCPY); > + if (!chan) { > + queue_mode = PMEM_Q_BIO; > + dev_warn(dev, "Forced back to PMEM_Q_BIO, no DMA\n"); > +

Re: [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper

On Wed, Aug 02 2017 at 1:57pm -0400, Dan Williams wrote: > Changes since v2 [1]: > * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make > sure dm_dax_flush() is called if device supports it" (kbuild robot) > * fix CONFIG_DAX dependencies to upgrade

[PATCH v2 0/5] Adding blk-mq and DMA support to pmem block driver

v2: - Make dma_prep_memcpy_* into one function per Dan. - Addressed various comments from Ross with code formatting and etc. - Replaced open code with offset_in_page() macro per Johannes. The following series implements adds blk-mq support to the pmem block driver and also adds infrastructure

[PATCH v2 4/5] libnvdimm: Adding blk-mq support to the pmem driver

Adding blk-mq support to the pmem driver in addition to the direct bio support. This allows for hardware offloading via DMA engines. By default the bio method will be enabled. The blk-mq support can be turned on via module parameter queue_mode=1. Signed-off-by: Dave Jiang

[PATCH v2 2/5] dmaengine: ioatdma: dma_prep_memcpy_sg support

Adding ioatdma support to copy from a physically contiguos buffer to a provided scatterlist and vice versa. This is used to support reading/writing persistent memory in the pmem driver. Signed-off-by: Dave Jiang --- drivers/dma/ioat/dma.h|4 +++

[PATCH v2 1/5] dmaengine: ioatdma: revert 7618d035 to allow sharing of DMA channels

Commit 7618d0359c16 ("dmaengine: ioatdma: Set non RAID channels to be private capable") makes all non-RAID ioatdma channels as private to be requestable by dma_request_channel(). With PQ CAP support going away for ioatdma, this would make all channels private. To support the usage of ioatdma for

[PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

Adding DMA support for pmem blk reads. This provides signficant CPU reduction with large memory reads with good performance. DMAs are triggered with test against bio_multiple_segment(), so the small I/Os (4k or less?) are still performed by the CPU in order to reduce latency. By default the pmem

Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

On 8/2/2017 4:52 PM, Dave Jiang wrote: >> Do we need a new API / new function, or new capability? > Hmmm...you are right. I wonder if we need something like DMA_SG cap > > Unfortunately, DMA_SG means something else. Maybe, we need DMA_MEMCPY_SG to be similar with DMA_MEMSET_SG. enum

[PATCH v2 3/5] dmaengine: add SG support to dmaengine_unmap

This should provide support to unmap scatterlist with the dmaengine_unmap_data. We will support only 1 scatterlist per direction. The DMA addresses array has been overloaded for the 2 or less entries DMA unmap data structure in order to store the SG pointer(s). Signed-off-by: Dave Jiang

Re: [PATCH v2] dm: allow device-mapper to operate without dax support

Hi Dan, [auto build test ERROR on dm/for-next] [also build test ERROR on v4.13-rc3 next-20170802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dan-Williams/dm-allow-device-mapper-to-operate

Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

On 08/02/2017 12:22 PM, Sinan Kaya wrote: > On 8/2/2017 2:41 PM, Dave Jiang wrote: >> if (queue_mode == PMEM_Q_MQ) { >> +chan = dma_find_channel(DMA_MEMCPY); >> +if (!chan) { >> +queue_mode = PMEM_Q_BIO; >> +dev_warn(dev,

Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

On 08/02/2017 02:10 PM, Sinan Kaya wrote: > On 8/2/2017 4:52 PM, Dave Jiang wrote: >>> Do we need a new API / new function, or new capability? >> Hmmm...you are right. I wonder if we need something like DMA_SG cap >> >> > > Unfortunately, DMA_SG means something else. Maybe, we need

Re: [PATCH] nvdimm: avoid bogus -Wmaybe-uninitialized warning

On Wed, Aug 2, 2017 at 12:23 AM, Ross Zwisler wrote: > On Tue, Aug 01, 2017 at 02:45:34PM -0700, Andrew Morton wrote: >> On Tue, 1 Aug 2017 13:48:48 +0200 Arnd Bergmann wrote: >> > --- a/drivers/nvdimm/nd.h >> > +++ b/drivers/nvdimm/nd.h >> > @@

Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

On Thu, Aug 03, 2017 at 10:41:51AM +0530, Jiang, Dave wrote: > > > > On Aug 2, 2017, at 9:58 PM, Koul, Vinod wrote: > > > >> On Wed, Aug 02, 2017 at 02:13:56PM -0700, Dave Jiang wrote: > >> > >> > >>> On 08/02/2017 02:10 PM, Sinan Kaya wrote: > >>> On 8/2/2017 4:52 PM,

Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

> On Aug 2, 2017, at 9:58 PM, Koul, Vinod wrote: > >> On Wed, Aug 02, 2017 at 02:13:56PM -0700, Dave Jiang wrote: >> >> >>> On 08/02/2017 02:10 PM, Sinan Kaya wrote: >>> On 8/2/2017 4:52 PM, Dave Jiang wrote: > Do we need a new API / new function, or new capability?

Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

On Wed, Aug 02, 2017 at 02:13:56PM -0700, Dave Jiang wrote: > > > On 08/02/2017 02:10 PM, Sinan Kaya wrote: > > On 8/2/2017 4:52 PM, Dave Jiang wrote: > >>> Do we need a new API / new function, or new capability? > >> Hmmm...you are right. I wonder if we need something like DMA_SG cap > >> >

Re: [PATCH v2 5/5] libnvdimm: add DMA support for pmem blk-mq

> On Aug 2, 2017, at 10:25 PM, Koul, Vinod wrote: > >> On Thu, Aug 03, 2017 at 10:41:51AM +0530, Jiang, Dave wrote: >> >> On Aug 2, 2017, at 9:58 PM, Koul, Vinod wrote: On Wed, Aug 02, 2017 at 02:13:56PM -0700, Dave Jiang wrote:

门店管理七大核心问题解决模板

___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

制造业新产品导入与NPI实务

___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v2] dm: allow device-mapper to operate without dax support

Hi Dan, [auto build test ERROR on dm/for-next] [also build test ERROR on v4.13-rc3 next-20170802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dan-Williams/dm-allow-device-mapper-to-operate

[PATCH v3 1/2] dax: introduce CONFIG_DAX_DRIVER

In support of allowing device-mapper to compile out idle/dead code when there are no dax providers in the system, introduce the DAX_DRIVER symbol. This is selected by all leaf drivers that device-mapper might be layered on top. This allows device-mapper to 'select DAX', i.e. upgrade it from DAX=m

[PATCH v3 2/2] dm: allow device-mapper to operate without dax support

Rather than have device-mapper directly 'select DAX', let the fact that BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax support. We arrange for all the dax core routines to compile to nops when CONFIG_DAX=n. With that in place we can simply handle the alloc_dax() error as expected

[PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper

Changes since v2 [1]: * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make sure dm_dax_flush() is called if device supports it" (kbuild robot) * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y (kbuild robot) [1]: