Re: [PATCH] blk-mq: Improvements to the hybrid polling sleep time calculation

>> From: Stephen Bates <sba...@raithlin.com> >> >> Hybrid polling currently uses half the average completion time as an >> estimate of how long to poll for. We can improve upon this by noting >> that polling before the minimum completion time makes no sense. A

Re: [PATCH] blk-mq: Improvements to the hybrid polling sleep time calculation

>> From: Stephen Bates >> >> Hybrid polling currently uses half the average completion time as an >> estimate of how long to poll for. We can improve upon this by noting >> that polling before the minimum completion time makes no sense. Add a >> sysfs e

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

> +#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p)) Logan, thanks for taking this cleanup on. I think this should be iowrite64 not iowrite32? Stephen

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

> +#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p)) Logan, thanks for taking this cleanup on. I think this should be iowrite64 not iowrite32? Stephen

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

>> Yes, that's why I used 'significant'. One good thing is that given resources >> it can easily be done in parallel with other development, and will give >> additional >> insight of some form. > >Yup, well if someone wants to start working on an emulated RDMA device >that actually simulates

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

>> Yes, that's why I used 'significant'. One good thing is that given resources >> it can easily be done in parallel with other development, and will give >> additional >> insight of some form. > >Yup, well if someone wants to start working on an emulated RDMA device >that actually simulates

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

> My first reflex when reading this thread was to think that this whole domain > lends it self excellently to testing via Qemu. Could it be that doing this in > the opposite direction might be a safer approach in the long run even though > (significant) more work up-front? While the idea of

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

> My first reflex when reading this thread was to think that this whole domain > lends it self excellently to testing via Qemu. Could it be that doing this in > the opposite direction might be a safer approach in the long run even though > (significant) more work up-front? While the idea of

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

>> Yes, this makes sense I think we really just want to distinguish host >> memory or not in terms of the dev_pagemap type. > >> I would like to see mutually exclusive flags for host memory (or not) and >> persistence (or not). >> > > Why persistence? It has zero meaning to the mm. I like the

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

>> Yes, this makes sense I think we really just want to distinguish host >> memory or not in terms of the dev_pagemap type. > >> I would like to see mutually exclusive flags for host memory (or not) and >> persistence (or not). >> > > Why persistence? It has zero meaning to the mm. I like the

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

> Yes, this makes sense I think we really just want to distinguish host > memory or not in terms of the dev_pagemap type. I would like to see mutually exclusive flags for host memory (or not) and persistence (or not). Stephen

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

> Yes, this makes sense I think we really just want to distinguish host > memory or not in terms of the dev_pagemap type. I would like to see mutually exclusive flags for host memory (or not) and persistence (or not). Stephen

Kernel Oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050; IP is at blk_mq_poll+0xa0/0x2e0

Hi All As part of my testing of IO polling [1] I am seeing a NULL pointer dereference oops that seems to have been introduced in the preparation for 4.11. The kernel oops output is below and this seems to be due to blk_mq_tag_to_rq returning NULL in blk_mq_poll in blk-mq.c. I have not had a

Kernel Oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050; IP is at blk_mq_poll+0xa0/0x2e0

Hi All As part of my testing of IO polling [1] I am seeing a NULL pointer dereference oops that seems to have been introduced in the preparation for 4.11. The kernel oops output is below and this seems to be due to blk_mq_tag_to_rq returning NULL in blk_mq_poll in blk-mq.c. I have not had a

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

On 2017-04-06, 6:33 AM, "Sagi Grimberg" wrote: > Say it's connected via 2 legs, the bar is accessed from leg A and the > data from the disk comes via leg B. In this case, the data is heading > towards the p2p device via leg B (might be congested), the completion > goes directly

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

On 2017-04-06, 6:33 AM, "Sagi Grimberg" wrote: > Say it's connected via 2 legs, the bar is accessed from leg A and the > data from the disk comes via leg B. In this case, the data is heading > towards the p2p device via leg B (might be congested), the completion > goes directly to the RC, and

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote: > > > On 06/01/17 11:26 AM, Jason Gunthorpe wrote: > > >> Make a generic API for all of this and you'd have my vote.. >> >> >> IMHO, you must support basic pinning semantics - that is necessary to >> support generic short lived DMA (eg

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote: > > > On 06/01/17 11:26 AM, Jason Gunthorpe wrote: > > >> Make a generic API for all of this and you'd have my vote.. >> >> >> IMHO, you must support basic pinning semantics - that is necessary to >> support generic short lived DMA (eg

Re: [PATCH 2/2] nvme: improve cmb sysfs reporting

> Minor nit below > > >> + >> +for (i = NVME_CMB_CAP_SQS; i <= NVME_CMB_CAP_WDS; i++) >> > I'd prefer seeing (i = 0; i < ARRAY_SIZE(..); i++) because it provides > automatic bounds checking against future code. > Thanks Jon, I will take a look at doing this in a V1. Stephen

Re: [PATCH 2/2] nvme: improve cmb sysfs reporting

> Minor nit below > > >> + >> +for (i = NVME_CMB_CAP_SQS; i <= NVME_CMB_CAP_WDS; i++) >> > I'd prefer seeing (i = 0; i < ARRAY_SIZE(..); i++) because it provides > automatic bounds checking against future code. > Thanks Jon, I will take a look at doing this in a V1. Stephen

Re: [PATCH 0/2] nvme: Improvements in sysfs entry for NVMe CMBs

> > I have added 1/2, since that one is a no-brainer. For 2/2, not so sure. > Generally we try to avoid having sysfs file that aren't single value > output. That isn't a super hard rule, but it is preferable. > > -- > Jens Axboe > Thanks Jens and sorry for the delay (extended vacation). Thanks

Re: [PATCH 0/2] nvme: Improvements in sysfs entry for NVMe CMBs

> > I have added 1/2, since that one is a no-brainer. For 2/2, not so sure. > Generally we try to avoid having sysfs file that aren't single value > output. That isn't a super hard rule, but it is preferable. > > -- > Jens Axboe > Thanks Jens and sorry for the delay (extended vacation). Thanks

[PATCH 0/2] nvme: Improvements in sysfs entry for NVMe CMBs

Hi This series adds some more verbosity to the NVMe CMB sysfs entry. Jens I based this off v4.9 because for some reason your for-4.10/block is missing my original CMB commit (202021c1a63c6)? Stephen Stephen Bates (2): nvme : Use correct scnprintf in cmb show nvme: improve cmb sysfs

[PATCH 1/2] nvme : Use correct scnprintf in cmb show

Make sure we are using the correct scnprintf in the sysfs show function for the CMB. Signed-off-by: Stephen Bates <sba...@raithlin.com> --- drivers/nvme/host/pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c

[PATCH 0/2] nvme: Improvements in sysfs entry for NVMe CMBs

Hi This series adds some more verbosity to the NVMe CMB sysfs entry. Jens I based this off v4.9 because for some reason your for-4.10/block is missing my original CMB commit (202021c1a63c6)? Stephen Stephen Bates (2): nvme : Use correct scnprintf in cmb show nvme: improve cmb sysfs

[PATCH 1/2] nvme : Use correct scnprintf in cmb show

Make sure we are using the correct scnprintf in the sysfs show function for the CMB. Signed-off-by: Stephen Bates --- drivers/nvme/host/pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 5e52034..be10860 100644

Re: [PATCH 0/2] nvme: Improvements in sysfs entry for NVMe CMBs

>> Jens I based this off v4.9 because for some reason your for-4.10/block >> is missing my original CMB commit (202021c1a63c6)? > > for-4.10/block was forked off v4.9-rc1, and that patch didn't make it in > until v4.9-rc2. Since for-4.10/block has been merged, any patches for this > series or next

Re: [PATCH 0/2] nvme: Improvements in sysfs entry for NVMe CMBs

>> Jens I based this off v4.9 because for some reason your for-4.10/block >> is missing my original CMB commit (202021c1a63c6)? > > for-4.10/block was forked off v4.9-rc1, and that patch didn't make it in > until v4.9-rc2. Since for-4.10/block has been merged, any patches for this > series or next

[PATCH 2/2] nvme: improve cmb sysfs reporting

Add more information to the NVMe CMB sysfs entry. This includes information about the CMB size, location and capabilities. Signed-off-by: Stephen Bates <sba...@raithlin.com> --- drivers/nvme/host/pci.c | 31 +-- include/linux/nvme.h| 8 2 files c

[PATCH 2/2] nvme: improve cmb sysfs reporting

Add more information to the NVMe CMB sysfs entry. This includes information about the CMB size, location and capabilities. Signed-off-by: Stephen Bates --- drivers/nvme/host/pci.c | 31 +-- include/linux/nvme.h| 8 2 files changed, 37 insertions(+), 2

[LSF/MM TOPIC][LSF/MM ATTEND] Enabling Peer-to-Peer DMAs between PCIe devices

Hi I'd like to discuss the topic of how best to enable DMAs between PCIe devices in the Linux kernel. There have been many attempts to add to the kernel the ability to DMA between two PCIe devices. However, to date, none of these have been accepted. However as PCIe devices like NICs, NVMe SSDs

[LSF/MM TOPIC][LSF/MM ATTEND] Enabling Peer-to-Peer DMAs between PCIe devices

Hi I'd like to discuss the topic of how best to enable DMAs between PCIe devices in the Linux kernel. There have been many attempts to add to the kernel the ability to DMA between two PCIe devices. However, to date, none of these have been accepted. However as PCIe devices like NICs, NVMe SSDs

Re: Enabling peer to peer device transactions for PCIe devices

>>> I've already recommended that iopmem not be a block device and >>> instead be a device-dax instance. I also don't think it should claim >>> the PCI ID, rather the driver that wants to map one of its bars this >>> way can register the memory region with the device-dax core. >>> >>> I'm not sure

Re: Enabling peer to peer device transactions for PCIe devices

>>> I've already recommended that iopmem not be a block device and >>> instead be a device-dax instance. I also don't think it should claim >>> the PCI ID, rather the driver that wants to map one of its bars this >>> way can register the memory region with the device-dax core. >>> >>> I'm not sure

Re: Enabling peer to peer device transactions for PCIe devices

Hi All This has been a great thread (thanks to Alex for kicking it off) and I wanted to jump in and maybe try and put some summary around the discussion. I also wanted to propose we include this as a topic for LFS/MM because I think we need more discussion on the best way to add this

Re: Enabling peer to peer device transactions for PCIe devices

Hi All This has been a great thread (thanks to Alex for kicking it off) and I wanted to jump in and maybe try and put some summary around the discussion. I also wanted to propose we include this as a topic for LFS/MM because I think we need more discussion on the best way to add this

Re: Enabling peer to peer device transactions for PCIe devices

>> >> The NVMe fabrics stuff could probably make use of this. It's an >> in-kernel system to allow remote access to an NVMe device over RDMA. So >> they ought to be able to optimize their transfers by DMAing directly to >> the NVMe's CMB -- no userspace interface would be required but there >>

Re: Enabling peer to peer device transactions for PCIe devices

>> >> The NVMe fabrics stuff could probably make use of this. It's an >> in-kernel system to allow remote access to an NVMe device over RDMA. So >> they ought to be able to optimize their transfers by DMAing directly to >> the NVMe's CMB -- no userspace interface would be required but there >>

Re: [PATCHSET v2] block: IO polling improvements

> Fixed a few bugs in this, and addressed some review comments. Patches > are against my 4.10 block branch, for-4.10/block. Jens Thanks for proposing this. Looks very cool. I will try and get you a review and some testing this week... Cheers Stephen

Re: [PATCHSET v2] block: IO polling improvements

> Fixed a few bugs in this, and addressed some review comments. Patches > are against my 4.10 block branch, for-4.10/block. Jens Thanks for proposing this. Looks very cool. I will try and get you a review and some testing this week... Cheers Stephen

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

On Tue, October 25, 2016 3:19 pm, Dave Chinner wrote: > On Tue, Oct 25, 2016 at 05:50:43AM -0600, Stephen Bates wrote: >> >> Dave are you saying that even for local mappings of files on a DAX >> capable system it is possible for the mappings to move on you unless the &

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

On Tue, October 25, 2016 3:19 pm, Dave Chinner wrote: > On Tue, Oct 25, 2016 at 05:50:43AM -0600, Stephen Bates wrote: >> >> Dave are you saying that even for local mappings of files on a DAX >> capable system it is possible for the mappings to move on you unless the &

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

Hi Dave and Christoph On Fri, Oct 21, 2016 at 10:12:53PM +1100, Dave Chinner wrote: > On Fri, Oct 21, 2016 at 02:57:14AM -0700, Christoph Hellwig wrote: > > On Fri, Oct 21, 2016 at 10:22:39AM +1100, Dave Chinner wrote: > > > You do realise that local filesystems can silently change the > > >

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

Hi Dave and Christoph On Fri, Oct 21, 2016 at 10:12:53PM +1100, Dave Chinner wrote: > On Fri, Oct 21, 2016 at 02:57:14AM -0700, Christoph Hellwig wrote: > > On Fri, Oct 21, 2016 at 10:22:39AM +1100, Dave Chinner wrote: > > > You do realise that local filesystems can silently change the > > >

Re: [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages.

On Wed, Oct 19, 2016 at 01:01:06PM -0700, Dan Williams wrote: > >> > >> In the cover letter, "[PATCH 0/3] iopmem : A block device for PCIe > >> memory", it mentions that the lack of I/O coherency is a known issue > >> and users of this functionality need to be cognizant of the pitfalls. > >> If

Re: [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages.

On Wed, Oct 19, 2016 at 01:01:06PM -0700, Dan Williams wrote: > >> > >> In the cover letter, "[PATCH 0/3] iopmem : A block device for PCIe > >> memory", it mentions that the lack of I/O coherency is a known issue > >> and users of this functionality need to be cognizant of the pitfalls. > >> If

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

> >> > >> If you're only using the block-device as a entry-point to create > >> dax-mappings then a device-dax (drivers/dax/) character-device might > >> be a better fit. > >> > > > > We chose a block device because we felt it was intuitive for users to > > carve up a memory region but putting a

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

> >> > >> If you're only using the block-device as a entry-point to create > >> dax-mappings then a device-dax (drivers/dax/) character-device might > >> be a better fit. > >> > > > > We chose a block device because we felt it was intuitive for users to > > carve up a memory region but putting a

Re: [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages.

On Wed, Oct 19, 2016 at 10:50:25AM -0700, Dan Williams wrote: > On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates <sba...@raithlin.com> wrote: > > From: Logan Gunthorpe <log...@deltatee.com> > > > > We build on recent work that adds memory regions owned by a d

Re: [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages.

On Wed, Oct 19, 2016 at 10:50:25AM -0700, Dan Williams wrote: > On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates wrote: > > From: Logan Gunthorpe > > > > We build on recent work that adds memory regions owned by a device > > driver (ZONE_DEVICE) [1] and to add struct

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

On Tue, Oct 18, 2016 at 08:51:15PM -0700, Dan Williams wrote: > [ adding Ashok and David for potential iommu comments ] > Hi Dan Thanks for adding Ashok and David! > > I agree with the motivation and the need for a solution, but I have > some questions about this implementation. > > > > >

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

On Tue, Oct 18, 2016 at 08:51:15PM -0700, Dan Williams wrote: > [ adding Ashok and David for potential iommu comments ] > Hi Dan Thanks for adding Ashok and David! > > I agree with the motivation and the need for a solution, but I have > some questions about this implementation. > > > > >

[PATCH 2/3] iopmem : Add a block device driver for PCIe attached IO memory.

Add a new block device driver that binds to PCIe devices and turns PCIe BARs into DAX capable block devices. Signed-off-by: Stephen Bates <sba...@raithlin.com> Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- MAINTAINERS| 7 ++ drivers/block/Kconfig | 27 +

[PATCH 2/3] iopmem : Add a block device driver for PCIe attached IO memory.

Add a new block device driver that binds to PCIe devices and turns PCIe BARs into DAX capable block devices. Signed-off-by: Stephen Bates Signed-off-by: Logan Gunthorpe --- MAINTAINERS| 7 ++ drivers/block/Kconfig | 27 drivers/block/Makefile | 1 + drivers/block

[PATCH 0/3] iopmem : A block device for PCIe memory

IO memory with struct pages. Stephen Bates (2): iopmem : Add a block device driver for PCIe attached IO memory. iopmem : Add documentation for iopmem driver Documentation/blockdev/00-INDEX | 2 + Documentation/blockdev/iopmem.txt | 62 +++ MAINTAINERS | 7

[PATCH 0/3] iopmem : A block device for PCIe memory

IO memory with struct pages. Stephen Bates (2): iopmem : Add a block device driver for PCIe attached IO memory. iopmem : Add documentation for iopmem driver Documentation/blockdev/00-INDEX | 2 + Documentation/blockdev/iopmem.txt | 62 +++ MAINTAINERS | 7

[PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages.

https://lists.01.org/pipermail/linux-nvdimm/2015-August/001810.html [2] https://lists.01.org/pipermail/linux-nvdimm/2015-October/002387.html Signed-off-by: Stephen Bates <sba...@raithlin.com> Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/dax/pmem.c| 4

[PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages.

/linux-nvdimm/2015-August/001810.html [2] https://lists.01.org/pipermail/linux-nvdimm/2015-October/002387.html Signed-off-by: Stephen Bates Signed-off-by: Logan Gunthorpe --- drivers/dax/pmem.c| 4 +- drivers/nvdimm/pmem.c | 4 +- include/linux/memremap.h

[PATCH 3/3] iopmem : Add documentation for iopmem driver

Add documentation for the iopmem PCIe device driver. Signed-off-by: Stephen Bates <sba...@raithlin.com> Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- Documentation/blockdev/00-INDEX | 2 ++ Documentation/blockdev/iopmem.txt | 62

[PATCH 3/3] iopmem : Add documentation for iopmem driver

Add documentation for the iopmem PCIe device driver. Signed-off-by: Stephen Bates Signed-off-by: Logan Gunthorpe --- Documentation/blockdev/00-INDEX | 2 ++ Documentation/blockdev/iopmem.txt | 62 +++ 2 files changed, 64 insertions(+) create mode 100644

RE: [PATCH v4 0/8] Support for Open-Channel SSDs

). Tested-by: Stephen Bates Cheers Stephen -Original Message- From: Matias Bjørling [mailto:m...@bjorling.me] Sent: Friday, June 5, 2015 6:54 AM To: h...@infradead.org; ax...@fb.com; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-n...@lists.infradead.org Cc: jav

RE: [PATCH v4 0/8] Support for Open-Channel SSDs

). Tested-by: Stephen Bates stephen.ba...@pmcs.com Cheers Stephen -Original Message- From: Matias Bjørling [mailto:m...@bjorling.me] Sent: Friday, June 5, 2015 6:54 AM To: h...@infradead.org; ax...@fb.com; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-n

<    1   2