Re: [PATCH] bcache: remove closure debug file when unloading module

From: Tang Junhui Hello Chengguang >When unloading bcache module there is lack of removing >operation for closure debug file, so it will cause >creating error when trying to reload module. > Yes, This issue is true. Actually, the original code try to remove closure

Re: [PATCH] bcache: don't attach backing with duplicate UUID

From: Tang Junhui Hello, Mike This patch looks good, but has some conflicts with this patch: bcache: fix for data collapse after re-attaching an attached device

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, Mar 01, 2018 at 04:19:34PM -0500, Laurence Oberman wrote: > On Thu, 2018-03-01 at 14:01 -0500, Laurence Oberman wrote: > > On Thu, 2018-03-01 at 16:18 +, Don Brace wrote: > > > > -Original Message- > > > > From: Ming Lei [mailto:ming@redhat.com] > > > > Sent: Tuesday,

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

Hi Don, Thanks for your test! On Thu, Mar 01, 2018 at 04:18:17PM +, Don Brace wrote: > > -Original Message- > > From: Ming Lei [mailto:ming@redhat.com] > > Sent: Tuesday, February 27, 2018 4:08 AM > > To: Jens Axboe ; linux-block@vger.kernel.org; Christoph > >

Re: [PATCH v2 02/10] PCI/P2PDMA: Add sysfs group to display p2pmem stats

On 01/03/18 05:36 PM, Dan Williams wrote: On Thu, Mar 1, 2018 at 4:15 PM, Logan Gunthorpe wrote: On 01/03/18 10:44 AM, Bjorn Helgaas wrote: I think these two statements are out of order, since the attributes dereference pdev->p2pdma. And it looks like you set

Re: [PATCH v2 02/10] PCI/P2PDMA: Add sysfs group to display p2pmem stats

On Thu, Mar 1, 2018 at 4:15 PM, Logan Gunthorpe wrote: > > > On 01/03/18 10:44 AM, Bjorn Helgaas wrote: >> >> I think these two statements are out of order, since the attributes >> dereference pdev->p2pdma. And it looks like you set "error" >> unnecessarily, since you return

Re: [PATCH v2 02/10] PCI/P2PDMA: Add sysfs group to display p2pmem stats

On 01/03/18 10:44 AM, Bjorn Helgaas wrote: I think these two statements are out of order, since the attributes dereference pdev->p2pdma. And it looks like you set "error" unnecessarily, since you return immediately looking at it. Per the previous series, sysfs_create_group is must_check for

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On 01/03/18 04:57 PM, Stephen Bates wrote: We don't want to lump these all together without knowing which region you're allocating from, right? In all seriousness I do agree with you on these Keith in the long term. We would consider adding property flags for the memory as it is added to

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 01/03/18 04:15 PM, Bjorn Helgaas wrote: The question is what the relevant switch is. We call pci_enable_acs() on every PCI device, including Root Ports. It looks like this relies on get_upstream_bridge_port() to filter out some things. I don't think get_upstream_bridge_port() is doing

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

> We don't want to lump these all together without knowing which region you're > allocating from, right? In all seriousness I do agree with you on these Keith in the long term. We would consider adding property flags for the memory as it is added to the p2p core and then the allocator could

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 04:26 PM, Benjamin Herrenschmidt wrote: The big problem is not the vmemmap, it's the linear mapping. Ah, yes, ok. Logan

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

> There's a meaningful difference between writing to an NVMe CMB vs PMR When the PMR spec becomes public we can discuss how best to integrate it into the P2P framework (if at all) ;-). Stephen

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On 01/03/18 04:49 PM, Keith Busch wrote: On Thu, Mar 01, 2018 at 11:00:51PM +, Stephen Bates wrote: P2P is about offloading the memory and PCI subsystem of the host CPU and this is achieved no matter which p2p_dev is used. Even within a device, memory attributes for its various

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On Thu, Mar 01, 2018 at 11:00:51PM +, Stephen Bates wrote: > > P2P is about offloading the memory and PCI subsystem of the host CPU > and this is achieved no matter which p2p_dev is used. Even within a device, memory attributes for its various regions may not be the same. There's a

Re: [PATCH v2 01/10] PCI/P2PDMA: Support peer to peer memory

On Thu, Mar 01, 2018 at 11:14:46PM +, Stephen Bates wrote: > > I'm pretty sure the spec disallows routing-to-self so doing a P2P > > transaction in that sense isn't going to work unless the device > > specifically supports it and intercepts the traffic before it gets to > > the port. > >

Re: [bug report] Don't enter SCSI error handler on kernel 4.16-rc1

On Wed, 2018-02-28 at 14:17 +0800, chenxiang (M) wrote: > It seems the patch is for block mq, but the issue i encount is under > block legacy as CONFIG_SCSI_MQ_DEFAULT is not enabled. Since the call traces refer to the ATA code I hope that an ATA expert will have the time to help you further.

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

> No, locality matters. If you have a bunch of NICs and bunch of drives > and the allocator chooses to put all P2P memory on a single drive your > performance will suck horribly even if all the traffic is offloaded. Sagi brought this up earlier in his comments about the _find_ function.

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On 01/03/18 04:20 PM, Jason Gunthorpe wrote: On Thu, Mar 01, 2018 at 11:00:51PM +, Stephen Bates wrote: No, locality matters. If you have a bunch of NICs and bunch of drives and the allocator chooses to put all P2P memory on a single drive your performance will suck horribly even if

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote: (Switching back to my non-IBM address ...) > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: > > We use only 52 in practice but yes. > > > > > That's 64PB. If you use need > > > a sparse vmemmap for the entire space it will take

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote: > > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: > > We use only 52 in practice but yes. > > > > > That's 64PB. If you use need > > > a sparse vmemmap for the entire space it will take 16TB which leaves you > > > with 63.98PB of

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On Thu, Mar 01, 2018 at 11:00:51PM +, Stephen Bates wrote: > > Seems like a very subtle and hard to debug performance trap to leave > > for the users, and pretty much the only reason to use P2P is > > performance... So why have such a dangerous interface? > > P2P is about offloading the

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: We use only 52 in practice but yes. That's 64PB. If you use need a sparse vmemmap for the entire space it will take 16TB which leaves you with 63.98PB of address space left. (Similar calculations for other numbers of address bits.) We

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On Thu, Mar 01, 2018 at 06:54:01PM +, Stephen Bates wrote: > Thanks for the detailed review Bjorn! > > >> +Enabling this option will also disable ACS on all ports behind > >> +any PCIe switch. This effictively puts all devices behind any > >> +switch into the same IOMMU group. >

Re: [PATCH v2 01/10] PCI/P2PDMA: Support peer to peer memory

> I'm pretty sure the spec disallows routing-to-self so doing a P2P > transaction in that sense isn't going to work unless the device > specifically supports it and intercepts the traffic before it gets to > the port. This is correct. Unless the device intercepts the TLP before it hits the

Re: [PATCH v2 01/10] PCI/P2PDMA: Support peer to peer memory

I don't think this is correct. A Root Port defines a hierarchy domain (I'm looking at PCIe r4.0, sec 1.3.1). The capability to route peer-to-peer transactions *between* hierarchy domains is optional. I think this means a Root Complex is not required to route transactions from one Root Port

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:57 -0700, Logan Gunthorpe wrote: > > On 01/03/18 02:45 PM, Logan Gunthorpe wrote: > > It handles it fine for many situations. But when you try to map > > something that is at the end of the physical address space then the > > spares-vmemmap needs virtual address space

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

>> We'd prefer to have a generic way to get p2pmem instead of restricting >> ourselves to only using CMBs. We did work in the past where the P2P memory >> was part of an IB adapter and not the NVMe card. So this won't work if it's >> an NVMe only interface. > It just seems like it it

Re: [PATCH v2 01/10] PCI/P2PDMA: Support peer to peer memory

On Thu, Mar 01, 2018 at 11:55:51AM -0700, Logan Gunthorpe wrote: > Hi Bjorn, > > Thanks for the review. I'll correct all the nits for the next version. > > On 01/03/18 10:37 AM, Bjorn Helgaas wrote: > > On Wed, Feb 28, 2018 at 04:39:57PM -0700, Logan Gunthorpe wrote: > > > Some PCI devices may

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On 01/03/18 03:45 PM, Jason Gunthorpe wrote: I can appreciate you might have some special use case for that, but it absolutely should require special configuration and not just magically happen. Well if driver doesn't want someone doing p2p transfers with the memory it shouldn't publish it

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On Thu, Mar 01, 2018 at 12:27:03PM -0700, Logan Gunthorpe wrote: > > > On 01/03/18 11:42 AM, Jason Gunthorpe wrote: > >On Thu, Mar 01, 2018 at 08:35:55PM +0200, Sagi Grimberg wrote: > >This is also why I don't entirely understand why this series has a > >generic allocator for p2p mem, it makes

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:31 -0800, Linus Torvalds wrote: > On Thu, Mar 1, 2018 at 2:06 PM, Benjamin Herrenschmidt > wrote: > > > > Could be that x86 has the smarts to do the right thing, still trying to > > untangle the code :-) > > Afaik, x86 will not cache PCI unless the

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, Mar 1, 2018 at 2:06 PM, Benjamin Herrenschmidt wrote: > > Could be that x86 has the smarts to do the right thing, still trying to > untangle the code :-) Afaik, x86 will not cache PCI unless the system is misconfigured, and even then it's more likely to just raise a

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 13:53 -0700, Jason Gunthorpe wrote: > On Fri, Mar 02, 2018 at 07:40:15AM +1100, Benjamin Herrenschmidt wrote: > > Also we need to be able to hard block MEMREMAP_WB mappings of non-RAM > > on ppc64 (maybe via an arch hook as it might depend on the processor > > family). Server

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 02:45 PM, Logan Gunthorpe wrote: It handles it fine for many situations. But when you try to map something that is at the end of the physical address space then the spares-vmemmap needs virtual address space that's the size of the physical address space divided by PAGE_SIZE which

Re: [PATCH V3 0/8] blk-mq & scsi: fix reply queue selection and improve host wide tagset

On Tue, 2018-02-27 at 18:07 +0800, Ming Lei wrote: > Hi All, > > The 1st two patches fixes reply queue selection, and this issue has > been > reported and can cause IO hang during booting, please consider the > two > for V4.16. > > The following 6 patches try to improve hostwide tagset on hpsa

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 02:37 PM, Dan Williams wrote: Ah ok, I'd need to look at the details. I had been assuming that sparse-vmemmap could handle such a situation, but that could indeed be a broken assumption. It handles it fine for many situations. But when you try to map something that is at the end

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

> The intention of HMM is to be useful for all device memory that wish > to have struct page for various reasons. Hi Jermone and thanks for your input! Understood. We have looked at HMM in the past and long term I definitely would like to consider how we can add P2P functionality to HMM for

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 01/03/18 02:35 PM, Jerome Glisse wrote: Note that they are usecase for P2P where IOMMU isolation matter and the traffic through root complex isn't see as an issue. Well, we can worry about that once we have a solution to the problem of knowing whether a root complex supports P2P at all.

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, Mar 1, 2018 at 12:34 PM, Benjamin Herrenschmidt wrote: > On Thu, 2018-03-01 at 11:21 -0800, Dan Williams wrote: >> On Wed, Feb 28, 2018 at 7:56 PM, Benjamin Herrenschmidt >> wrote: >> > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote:

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On Thu, Mar 01, 2018 at 09:32:20PM +, Stephen Bates wrote: > > your kernel provider needs to decide whether they favor device assignment > > or p2p > > Thanks Alex! The hardware requirements for P2P (switch, high performance EPs) > are such that we really only expect CONFIG_P2P_DMA to be

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

> your kernel provider needs to decide whether they favor device assignment or > p2p Thanks Alex! The hardware requirements for P2P (switch, high performance EPs) are such that we really only expect CONFIG_P2P_DMA to be enabled in specific instances and in those instances the users have made a

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 01/03/18 02:21 PM, Alex Williamson wrote: This is still a pretty terrible solution though, your kernel provider needs to decide whether they favor device assignment or p2p, because we can't do both, unless there's a patch I haven't seen yet that allows boot time rather than compile time

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, Mar 01, 2018 at 02:15:01PM -0700, Logan Gunthorpe wrote: > > > On 01/03/18 02:10 PM, Jerome Glisse wrote: > > It seems people miss-understand HMM :( you do not have to use all of > > its features. If all you care about is having struct page then just > > use that for instance in your

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 02:18 PM, Jerome Glisse wrote: This is pretty easy to do with HMM: unsigned long hmm_page_to_phys_pfn(struct page *page) This is not useful unless you want to go through all the kernel paths we are using and replace page_to_phys() and friends with something else that calls an

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On Thu, 1 Mar 2018 18:54:01 + "Stephen Bates" wrote: > Thanks for the detailed review Bjorn! > > >> > >> +Enabling this option will also disable ACS on all ports behind > >> +any PCIe switch. This effictively puts all devices behind any > >> +switch into

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, Mar 01, 2018 at 02:11:34PM -0700, Logan Gunthorpe wrote: > > > On 01/03/18 02:03 PM, Benjamin Herrenschmidt wrote: > > However, what happens if anything calls page_address() on them ? Some > > DMA ops do that for example, or some devices might ... > > Although we could probably work

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, 2018-03-01 at 14:01 -0500, Laurence Oberman wrote: > On Thu, 2018-03-01 at 16:18 +, Don Brace wrote: > > > -Original Message- > > > From: Ming Lei [mailto:ming@redhat.com] > > > Sent: Tuesday, February 27, 2018 4:08 AM > > > To: Jens Axboe ;

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 02:10 PM, Jerome Glisse wrote: It seems people miss-understand HMM :( you do not have to use all of its features. If all you care about is having struct page then just use that for instance in your case only use those following 3 functions: hmm_devmem_add() or

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 02:03 PM, Benjamin Herrenschmidt wrote: However, what happens if anything calls page_address() on them ? Some DMA ops do that for example, or some devices might ... Although we could probably work around it with some pain, we rely on page_address() and virt_to_phys(), etc to

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, Mar 01, 2018 at 02:03:26PM -0700, Logan Gunthorpe wrote: > > > On 01/03/18 01:55 PM, Jerome Glisse wrote: > > Well this again a new user of struct page for device memory just for > > one usecase. I wanted HMM to be more versatile so that it could be use > > for this kind of thing too. I

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 01:55 PM, Jerome Glisse wrote: Well this again a new user of struct page for device memory just for one usecase. I wanted HMM to be more versatile so that it could be use for this kind of thing too. I guess the message didn't go through. I will take some cycles tomorrow to look

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:21 -0800, Dan Williams wrote: > > > The devm_memremap_pages() infrastructure allows placing the memmap in > "System-RAM" even if the hotplugged range is in PCI space. So, even if > it is an issue on some configurations, it's just a simple adjustment > to where the memmap

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 01:53 PM, Jason Gunthorpe wrote: On Fri, Mar 02, 2018 at 07:40:15AM +1100, Benjamin Herrenschmidt wrote: Also we need to be able to hard block MEMREMAP_WB mappings of non-RAM on ppc64 (maybe via an arch hook as it might depend on the processor family). Server powerpc cannot do

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, Mar 02, 2018 at 07:29:55AM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2018-03-01 at 11:04 -0700, Logan Gunthorpe wrote: > > > > On 28/02/18 08:56 PM, Benjamin Herrenschmidt wrote: > > > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > > > > The problem is that

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 01:29 PM, Benjamin Herrenschmidt wrote: Oliver can you look into this ? You sais the memory was effectively hotplug'ed into the system when creating the struct pages. That would mean to me that it's a) mapped (which for us is cachable, maybe x86 has tricks to avoid that) and b)

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, Mar 02, 2018 at 07:40:15AM +1100, Benjamin Herrenschmidt wrote: > Also we need to be able to hard block MEMREMAP_WB mappings of non-RAM > on ppc64 (maybe via an arch hook as it might depend on the processor > family). Server powerpc cannot do cachable accesses on IO memory > (unless it's

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, 2018-03-02 at 07:34 +1100, Benjamin Herrenschmidt wrote: > > But what happens with that PCI memory ? Is it effectively turned into > nromal memory (ie, usable for normal allocations, potentially used to > populate user pages etc...) or is it kept aside ? (What I mean is is it added to

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:21 -0800, Dan Williams wrote: > On Wed, Feb 28, 2018 at 7:56 PM, Benjamin Herrenschmidt > wrote: > > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > > > On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > > > > Hi Everyone, > >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 18:09 +, Stephen Bates wrote: > > > So Oliver (CC) was having issues getting any of that to work for us. > > > > > > The problem is that acccording to him (I didn't double check the latest > > > patches) you effectively hotplug the PCIe memory into the system when > > >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:04 -0700, Logan Gunthorpe wrote: > > On 28/02/18 08:56 PM, Benjamin Herrenschmidt wrote: > > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > > > The problem is that acccording to him (I didn't double check the latest > > > patches) you effectively

Re: EXT4 Oops (Re: [PATCH V15 06/22] mmc: block: Add blk-mq support)

On Mar 1, 2018, at 9:04 AM, Theodore Ts'o wrote: > This doesn't seem to make sense; the PC is where we are currently > executing, and LR is the "Link Register" where the flow of control > will be returning after the current function returns, right? Well, > dx_probe should *not*

Re: [PATCH v2 03/10] PCI/P2PDMA: Add PCI p2pmem dma mappings to adjust the bus offset

On 01/03/18 10:49 AM, Bjorn Helgaas wrote: +int pci_p2pdma_map_sg(struct device *dev, struct scatterlist *sg, int nents, + enum dma_data_direction dir) Same question as before about why the mixture of "pci_*" interfaces that take "struct device *" parameters. In this

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 03:31 AM, Sagi Grimberg wrote: * We also reject using devices that employ 'dma_virt_ops' which should    fairly simply handle Jason's concerns that this work might break with    the HFI, QIB and rxe drivers that use the virtual ops to implement    their own special DMA operations.

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 01/03/18 12:21 PM, Dan Williams wrote: Note: I think the above means it won't work behind a switch on x86 either, will it ? The devm_memremap_pages() infrastructure allows placing the memmap in "System-RAM" even if the hotplugged range is in PCI space. So, even if it is an issue on some

Re: [PATCH] lightnvm: pblk: refactor init/exit sequences

> On 1 Mar 2018, at 19.49, Matias Bjørling wrote: > > On 03/01/2018 04:59 PM, Javier González wrote: >> Refactor init and exit sequences to eliminate dependencies among init >> modules and improve readability. >> Signed-off-by: Javier González >> --- >>

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On 01/03/18 11:42 AM, Jason Gunthorpe wrote: On Thu, Mar 01, 2018 at 08:35:55PM +0200, Sagi Grimberg wrote: This is also why I don't entirely understand why this series has a generic allocator for p2p mem, it makes little sense to me. Why wouldn't the nmve driver just claim the entire CMB

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Wed, Feb 28, 2018 at 7:56 PM, Benjamin Herrenschmidt wrote: > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: >> On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: >> > Hi Everyone, >> >> >> So Oliver (CC) was having issues getting any of that to work

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On 01/03/18 11:02 AM, Bjorn Helgaas wrote: void pci_enable_acs(struct pci_dev *dev) { + if (pci_p2pdma_disable_acs(dev)) + return; This doesn't read naturally to me. I do see that when CONFIG_PCI_P2PDMA is not set, pci_p2pdma_disable_acs() does nothing and returns 0,

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

Wouldn't it all be simpler if the p2p_dev resolution would be private to the namespace? So is adding some all the namespaces in a subsystem must comply to using p2p? Seems a little bit harsh if its not absolutely needed. Would be nice to export a subsystems between two ports (on two HCAs,

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

> I agree, I don't think this series should target anything other than > using p2p memory located in one of the devices expected to participate > in the p2p trasnaction for a first pass.. I disagree. There is definitely interest in using a NVMe CMB as a bounce buffer and in deploying

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, 2018-03-01 at 16:18 +, Don Brace wrote: > > -Original Message- > > From: Ming Lei [mailto:ming@redhat.com] > > Sent: Tuesday, February 27, 2018 4:08 AM > > To: Jens Axboe ; linux-block@vger.kernel.org; > > Christoph > > Hellwig ; Mike

Re: [PATCH v2 01/10] PCI/P2PDMA: Support peer to peer memory

Hi Bjorn, Thanks for the review. I'll correct all the nits for the next version. On 01/03/18 10:37 AM, Bjorn Helgaas wrote: On Wed, Feb 28, 2018 at 04:39:57PM -0700, Logan Gunthorpe wrote: Some PCI devices may have memory mapped in a BAR space that's intended for use in Peer-to-Peer

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

Thanks for the detailed review Bjorn! >> >> + Enabling this option will also disable ACS on all ports behind >> + any PCIe switch. This effictively puts all devices behind any >> + switch into the same IOMMU group. > > Does this really mean "all devices behind the same Root

Re: [PATCH] lightnvm: pblk: refactor init/exit sequences

On 03/01/2018 04:59 PM, Javier González wrote: Refactor init and exit sequences to eliminate dependencies among init modules and improve readability. Signed-off-by: Javier González --- drivers/lightnvm/pblk-init.c | 415 +-- 1

Re: [PATCH V2] lightnvm: pblk: remove unused variable

On 03/01/2018 11:24 AM, Javier González wrote: On 1 Mar 2018, at 11.07, Matias Bjørling wrote: On 02/28/2018 04:57 PM, Javier González wrote: # Changes since V1: - Rebase on top of latest 2.0 changes Javier González (1): lightnvm: pblk: remove unused variable

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On Thu, Mar 01, 2018 at 08:35:55PM +0200, Sagi Grimberg wrote: > > >On 01/03/18 04:03 AM, Sagi Grimberg wrote: > >>Can you describe what would be the plan to have it when these devices > >>do come along? I'd say that p2p_dev needs to become a nvmet_ns reference > >>and not from nvmet_ctrl. Then,

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On 01/03/18 04:03 AM, Sagi Grimberg wrote: Can you describe what would be the plan to have it when these devices do come along? I'd say that p2p_dev needs to become a nvmet_ns reference and not from nvmet_ctrl. Then, when cmb capable devices come along, the ns can prefer to use its own cmb

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

>> So Oliver (CC) was having issues getting any of that to work for us. >> >> The problem is that acccording to him (I didn't double check the latest >> patches) you effectively hotplug the PCIe memory into the system when >> creating struct pages. >> >> This cannot possibly work for us. First

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 28/02/18 08:56 PM, Benjamin Herrenschmidt wrote: On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: The problem is that acccording to him (I didn't double check the latest patches) you effectively hotplug the PCIe memory into the system when creating struct pages. This

Re: [PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

On Wed, Feb 28, 2018 at 04:40:00PM -0700, Logan Gunthorpe wrote: > For peer-to-peer transactions to work the downstream ports in each > switch must not have the ACS flags set. At this time there is no way > to dynamically change the flags and update the corresponding IOMMU > groups so this is done

Re: [PATCH v2 03/10] PCI/P2PDMA: Add PCI p2pmem dma mappings to adjust the bus offset

On Wed, Feb 28, 2018 at 04:39:59PM -0700, Logan Gunthorpe wrote: > The DMA address used when mapping PCI P2P memory must be the PCI bus > address. Thus, introduce pci_p2pmem_[un]map_sg() to map the correct > addresses when using P2P memory. > > For this, we assume that an SGL passed to these

Re: [PATCH v2 02/10] PCI/P2PDMA: Add sysfs group to display p2pmem stats

On Wed, Feb 28, 2018 at 04:39:58PM -0700, Logan Gunthorpe wrote: > Attributes display the total amount of P2P memory, the amount available > and whether it is published or not. Can you add enough text here to make the body of the changelog complete in itself? That might mean just repeating the

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On 01/03/18 04:03 AM, Sagi Grimberg wrote: Can you describe what would be the plan to have it when these devices do come along? I'd say that p2p_dev needs to become a nvmet_ns reference and not from nvmet_ctrl. Then, when cmb capable devices come along, the ns can prefer to use its own cmb

Re: [PATCH v2 01/10] PCI/P2PDMA: Support peer to peer memory

s/peer to peer/peer-to-peer/ to match text below and in spec. On Wed, Feb 28, 2018 at 04:39:57PM -0700, Logan Gunthorpe wrote: > Some PCI devices may have memory mapped in a BAR space that's > intended for use in Peer-to-Peer transactions. In order to enable > such transactions the memory must be

Re: [PATCH v2 06/10] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

Hey Sagi, Thanks for the review! On 01/03/18 03:32 AM, Sagi Grimberg wrote:   int rdma_rw_ctx_init(struct rdma_rw_ctx *ctx, struct ib_qp *qp, u8 port_num,   struct scatterlist *sg, u32 sg_cnt, u32 sg_offset, -    u64 remote_addr, u32 rkey, enum dma_data_direction dir) +   

Re: [PATCH 5/5] nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors

On Thu, Mar 01, 2018 at 01:52:20AM +0100, Christoph Hellwig wrote: > Looks fine, > > and we should pick this up for 4.16 independent of the rest, which > I might need a little more review time for. > > Reviewed-by: Christoph Hellwig Thanks, queued up for 4.16.

[PATCH] block: Suppress kernel-doc warnings triggered by blk-zoned.c

Avoid that building with W=1 causes the kernel-doc tool to complain about undocumented function arguments for the blk-zoned.c source file. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Damien Le Moal --- block/blk-zoned.c

RE: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Tuesday, February 27, 2018 4:08 AM > To: Jens Axboe ; linux-block@vger.kernel.org; Christoph > Hellwig ; Mike Snitzer > Cc: linux-s...@vger.kernel.org;

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

> > Ideally, we'd want to use an NVME CMB buffer as p2p memory. This would > > save an extra PCI transfer as the NVME card could just take the data > > out of it's own memory. However, at this time, cards with CMB buffers > > don't seem to be available. > Can you describe what would be the plan

Re: EXT4 Oops (Re: [PATCH V15 06/22] mmc: block: Add blk-mq support)

On Thu, Mar 01, 2018 at 01:15:24AM -0800, Jose R R wrote: > Probably it is not wise to place all your eggs (data) in one basket > (ext4) and diversify to viable alternatives which won't be affected by > UNIX 2038 year date problem, likewise? > < >

Re: EXT4 Oops (Re: [PATCH V15 06/22] mmc: block: Add blk-mq support)

On Thu, Mar 01, 2018 at 10:55:37AM +0200, Adrian Hunter wrote: > On 27/02/18 11:28, Adrian Hunter wrote: > > On 26/02/18 23:48, Dmitry Osipenko wrote: > >> But still something is wrong... I've been getting occasional EXT4 Ooops's, > >> like > >> the one below, and __wait_on_bit() is always

[PATCH] bcache: don't attach backing with duplicate UUID

This can happen e.g. during disk cloning. This is an incomplete fix: it does not catch duplicate UUIDs earlier when things are still unattached. It does not unregister the device. Further changes to cope better with this are planned but conflict with Coly's ongoing improvements to handling

[PATCH] lightnvm: pblk: refactor init/exit sequences

Refactor init and exit sequences to eliminate dependencies among init modules and improve readability. Signed-off-by: Javier González --- drivers/lightnvm/pblk-init.c | 415 +-- 1 file changed, 206 insertions(+), 209 deletions(-)

[PATCH V2] lightnvm: pblk: refactor init/exit sequences

# Changes since V1 - Remove double check for factory initialization The init/exit sequences have grown in a very bad way. Refactor them to eliminate dependencies across initialization modules. One of these dependencies caused a bad double free when introducing a preparation patch for 2.0 bad

Re: [PATCH v2 08/10] nvme-pci: Add support for P2P memory in requests

> Any plans adding the capability to nvme-rdma? Should be > straight-forward... In theory, the use-case would be rdma backend > fabric behind. Shouldn't be hard to test either... Nice idea Sagi. Yes we have been starting to look at that. Though again we would probably want to impose the

Re: [PATCH V2 0/4] fix a few problems in block layer

On 2/27/18 5:07 AM, Jiufei Xue wrote: > I have found a few problems while reviewing the patch 74d46992e0d9 > ("block: replace bi_bdev with a gendisk pointer and partitions index"), > So fix them. Applied 1-3 for 4.16, thanks. -- Jens Axboe

Re: [PATCH] mq-deadline: Make sure to always unlock zones

On 2/28/18 10:35 AM, Bart Van Assche wrote: > From: Damien Le Moal > > In case of a failed write request (all retries failed) and when using > libata, the SCSI error handler calls scsi_finish_command(). In the > case of blk-mq this means that scsi_mq_done() does not get

Re: [PATCH 04/11] block: Protect queue flag changes with the queue lock

On Thu, Mar 01, 2018 at 03:19:08PM +, Bart Van Assche wrote: > Hello Johannes, > > Since blk_poll_stats_enable() is called from the hot path (polling code) I > think we need the optimization of calling test_bit() before calling > test_and_set_bit(). I will restore the test_bit() call.

Re: [PATCH 04/11] block: Protect queue flag changes with the queue lock

On Thu, 2018-03-01 at 09:51 +0100, Johannes Thumshirn wrote: > On Wed, Feb 28, 2018 at 11:28:16AM -0800, Bart Van Assche wrote: > > static bool blk_poll_stats_enable(struct request_queue *q) > > { > > - if (test_bit(QUEUE_FLAG_POLL_STATS, >queue_flags) || > > -

[PATCH] lightnvm: pblk: refactor init/exit sequences

Refactor init and exit sequences to eliminate dependencies among init modules and improve readability. Signed-off-by: Javier González --- drivers/lightnvm/pblk-init.c | 412 +-- 1 file changed, 206 insertions(+), 206 deletions(-)

  1   2   >