On Wed, Jul 03, 2019 at 01:46:19PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> +#ifdef CONFIG_PCI_PRI
> +static void pci_pri_init(struct pci_dev *pdev)
> +{
> + u32 max_requests;
> + int pos;
> +
> + /*
> + * As per PCIe r4.0, sec 9.3.7.11, only PF is permitted to
>
On Thu, Aug 01, 2019 at 02:21:07PM -0700, sathyanarayanan kuppuswamy wrote:
> On 8/1/19 2:09 PM, Keith Busch wrote:
> > Rather than surround the call to pci_pri_init() with the #ifdef, you
> > should provide an empty function implementation when CONFIG_PCI_PRI is
> > not de
ctor for left nodes if 'numvecs' vectors
> have been spread.
>
> Also, if the specified cpumask for one numa node is empty, simply not
> spread vectors on this node.
>
> Cc: Christoph Hellwig
> Cc: Keith Busch
> Cc: linux-n...@lists.infradead.
On Fri, Aug 09, 2019 at 01:05:42AM -0700, Rafael J. Wysocki wrote:
> On Fri, Aug 9, 2019 at 12:16 AM Keith Busch wrote:
> >
> > The v3 series looks good to me.
> >
> > Reviewed-by: Keith Busch
> >
> > Bjorn,
> >
> > If you're okay with th
On Fri, Aug 09, 2019 at 12:28:43PM +0200, Lukas Wunner wrote:
> A sysfs request to enable or disable a PCIe hotplug slot should not
> return before it has been carried out. That is sought to be achieved
> by waiting until the controller's "pending_events" have been cleared.
>
> However the IRQ th
,12
> irq 33, cpu list 0-1
> irq 34, cpu list 3,5
> irq 35, cpu list 6-7
> irq 36, cpu list 8-9
> irq 37, cpu list 11,13
> irq 38, cpu list 14-15
>
> Without this patch, kernel warning is triggered on above situation, and
> allocation
ign at least 1 vector for remained nodes if 'numvecs' vectors
> have been handled already.
>
> Also, if the specified cpumask for one numa node is empty, simply not
> spread vectors on this node.
>
> Cc: Christoph Hellwig
> Cc: Keith Busch
> Cc: linux-n...@lists.infr
gt; irq 36, cpu list 8-9
> irq 37, cpu list 11,13
> irq 38, cpu list 14-15
>
> Without this patch, kernel warning is triggered on above situation, and
> allocation result was supposed to be 4 vectors for each node.
>
> Cc: Christoph Hellwig
> Cc: Ke
On Mon, Aug 19, 2019 at 04:33:45PM -0700, Ashton Holmes wrote:
> When playing certain games on my PC dmesg will start spitting out NVME
> timeout messages, this eventually results in BTRFS throwing errors and
> remounting itself as read only. The drive passes smart's health check and
> works fine w
RROR_RESPONSE definition
> PCI / PM: Decode D3cold power state correctly
> PCI / PM: Return error when changing power state from D3cold
Series looks good to me.
Reviewed-by: Keith Busch
On Thu, Jul 25, 2019 at 02:51:41AM -0700, Rafael J. Wysocki wrote:
> Hi Keith,
>
> Unfortunately,
>
> commit d916b1be94b6dc8d293abed2451f3062f6af7551
> Author: Keith Busch
> Date: Thu May 23 09:27:35 2019 -0600
>
> nvme-pci: use host managed power sta
On Tue, Jul 23, 2019 at 01:21:50PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> Currently, in native mode, DPC driver is configured to trigger DPC only
> for FATAL errors and hence it only supports port recovery for FATAL
> errors. But with Erro
On Thu, Jul 25, 2019 at 09:48:57PM +0200, Rafael J. Wysocki wrote:
> NVME Identify Controller:
> vid : 0x1c5c
> ssvid : 0x1c5c
> sn : MS92N171312902J0N
> mn : PC401 NVMe SK hynix 256GB
> fr : 80007E00
> rab : 2
> ieee: ace42e
> cmic: 0
> mdts:
On Thu, Jul 25, 2019 at 02:28:28PM -0600, Logan Gunthorpe wrote:
>
>
> On 2019-07-25 1:58 p.m., Keith Busch wrote:
> > On Thu, Jul 25, 2019 at 11:54:18AM -0600, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-07-25 11:50 a.m., Matthew Wilcox wrote:
>
On Tue, Aug 20, 2019 at 01:59:32AM -0700, John Garry wrote:
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index e8f7f179bf77..cb483a055512 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -966,9 +966,13 @@ irq_thread_check_affinity(struct irq_desc *desc,
> struct ir
On Wed, Aug 21, 2019 at 7:34 PM Ming Lei wrote:
> On Wed, Aug 21, 2019 at 04:27:00PM +, Long Li wrote:
> > Here is the command to benchmark it:
> >
> > fio --bs=4k --ioengine=libaio --iodepth=128
> > --filename=/dev/nvme0n1:/dev/nvme1n1:/dev/nvme2n1:/dev/nvme3n1:/dev/nvme4n1:/dev/nvme5n1:/dev
On Wed, Aug 07, 2019 at 02:53:44AM -0700, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> One of the modifications made by commit d916b1be94b6 ("nvme-pci: use
> host managed power state for suspend") was adding a pci_save_state()
> call to nvme_suspend() in order to prevent the PCI bus-lev
On Thu, Aug 08, 2019 at 09:04:28AM +0200, Thomas Gleixner wrote:
> On Wed, 7 Aug 2019, Jon Derrick wrote:
> > The current irq spreading algorithm spreads vectors amongst cpus evenly
> > per node. If a node has more cpus than another node, the extra vectors
> > being spread may not be reported back
On Thu, Aug 08, 2019 at 01:39:54PM -0500, Bjorn Helgaas wrote:
> On Thu, Aug 08, 2019 at 04:47:45PM +0200, Rafael J. Wysocki wrote:
> > On Thu, Aug 8, 2019 at 3:43 PM Bjorn Helgaas wrote:
> >
> > > IIUC the NVMe device will go to the desired package idle state if
> > > the link is in L0s or L1, b
The v3 series looks good to me.
Reviewed-by: Keith Busch
Bjorn,
If you're okay with the series, we can either take it through nvme,
or you can feel free to apply through pci, whichever you prefer.
Thanks,
Keith
On Thu, Aug 08, 2019 at 10:46:06PM +, Derrick, Jonathan wrote:
> On Thu, 2019-08-08 at 10:32 -0600, Keith Busch wrote:
> >
> > I think the real problem is the spread's vecs_per_node doesn't account
> > which nodes contribute more CPUs than others. For example
On Fri, Aug 30, 2019 at 06:01:39PM -0600, Logan Gunthorpe wrote:
> To fix this, assign the subsystem's instance based on the instance
> number of the controller's instance that first created it. There should
> always be fewer subsystems than controllers so the should not be a need
> to create extra
On Tue, Sep 03, 2019 at 10:08:01AM -0600, Logan Gunthorpe wrote:
> On 2019-08-31 9:29 a.m., Keith Busch wrote:
> > On Fri, Aug 30, 2019 at 06:01:39PM -0600, Logan Gunthorpe wrote:
> >> To fix this, assign the subsystem's instance based on the instance
> >> number o
gt; irq 36, cpu list 8-9
> irq 37, cpu list 11,13
> irq 38, cpu list 14-15
>
> Without this patch, kernel warning is triggered on above situation, and
> allocation result was supposed to be 4 vectors for each node.
>
> Cc: Christoph Hellwig
> Cc: Keith Bus
On Fri, Aug 16, 2019 at 12:43:02PM -0700, mario.limoncie...@dell.com wrote:
> > We need to coordinate with Jens, don't think its a good idea if I'll
> > just randomly get stuff from linus' tree and send an rc pull request.
>
> The dependent commit is in Linus' tree now.
> 4eaefe8c621c6195c91044396
On Mon, Aug 19, 2019 at 12:06:23AM -0700, Marta Rybczynska wrote:
> - On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
> > Sorry for not replying to the earlier version, and thanks for doing
> > this work.
> >
> > I wonder if instead of using our own structure we'd just use
> >
On Mon, Aug 19, 2019 at 11:56:28AM -0700, Sagi Grimberg wrote:
>
> >> - On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
> >>> Sorry for not replying to the earlier version, and thanks for doing
> >>> this work.
> >>>
> >>> I wonder if instead of using our own structure we'd jus
On Mon, Aug 19, 2019 at 02:17:44PM -0700, Sagi Grimberg wrote:
>
> - On 16 Aug, 2019, at 15:16, Christoph Hellwig h...@lst.de wrote:
> > Sorry for not replying to the earlier version, and thanks for doing
> > this work.
> >
> > I wonder if instead of using our own structur
>
> You can find EDR spec in the following link.
>
> https://members.pcisig.com/wg/PCI-SIG/document/12614
Thank you for sticking with this. I've reviewed the series and I think
this looks good for the next merge window.
Acked-by: Keith Busch
On Thu, Nov 19, 2020 at 10:59:19AM -0800, Tom Roeder wrote:
> This patch changes the NVMe PCI implementation to cache host_mem_descs
> in non-DMA memory instead of depending on descriptors stored in DMA
> memory. This change is needed under the malicious-hypervisor threat
> model assumed by the AMD
On Fri, Nov 20, 2020 at 09:02:43AM +0100, Christoph Hellwig wrote:
> On Thu, Nov 19, 2020 at 05:27:37PM -0800, Tom Roeder wrote:
> > This patch changes the NVMe PCI implementation to cache host_mem_descs
> > in non-DMA memory instead of depending on descriptors stored in DMA
> > memory. This change
ode either but I might have missed something of course.
I don't think you missed anything, and the series looks like a
reasonable cleanup. I suspect the code was left over from a time when we
didn't allocate the possible queues up-front.
Reviewed-by: Keith Busch
On Thu, Nov 12, 2020 at 04:45:35PM +0100, Niklas Schnelle wrote:
> You got to get something wrong, I hope in this case it's just the subject
> of the cover letter :D
I suppose the change logs could be worded a little better :)
> Thanks for the review, I appreciate it. Might be getting ahead of
>
On Fri, Nov 06, 2020 at 10:00:36AM -0700, Logan Gunthorpe wrote:
> Allow userspace to obtain CMB memory by mmaping the controller's
> char device. The mmap call allocates and returns a hunk of CMB memory,
> (the offset is ignored) so userspace does not have control over the
> address within the CMB
On Tue, Jun 30, 2020 at 04:01:45PM +0200, Maximilian Heyne wrote:
> On 6/30/20 3:36 PM, Christoph Hellwig wrote:
> > And actually - 1.0 did not have the concept of a subsystem. So having
> > a duplicate serial number for a 1.0 controller actually is a pretty
> > nasty bug. Can you point me to thi
On Fri, Jul 03, 2020 at 10:49:24AM +0800, Baolin Wang wrote:
> static blk_status_t nvme_map_data(struct nvme_dev *dev, struct request *req,
> @@ -844,7 +844,7 @@ static blk_status_t nvme_map_metadata(struct nvme_dev
> *dev, struct request *req,
> if (dma_mapping_error(dev->dev, iod->meta_dm
On Wed, Jun 24, 2020 at 09:34:08AM +0800, Baolin Wang wrote:
> OK, I understaood your concern. Now we will select the RR arbitration as
> default
> in nvme_enable_ctrl(), but for some cases, we will not set the arbitration
> burst
> values from userspace, and we still want to use the defaut arbit
On Tue, Jun 23, 2020 at 09:24:32PM +0800, Baolin Wang wrote:
> +void nvme_set_arbitration_burst(struct nvme_ctrl *ctrl)
> +{
> + u32 result;
> + int status;
> +
> + if (!ctrl->rab)
> + return;
> +
> + /*
> + * The Arbitration Burst setting indicates the maximum numb
On Tue, Jun 23, 2020 at 06:27:51PM +0200, Christoph Hellwig wrote:
> On Tue, Jun 23, 2020 at 09:24:33PM +0800, Baolin Wang wrote:
> > Introduce a new capability macro to indicate if the controller
> > supports the memory buffer or not, instead of reading the
> > NVME_REG_CMBSZ register.
>
> This i
On Mon, Jul 20, 2020 at 05:01:19PM -0600, Logan Gunthorpe wrote:
> On 2020-07-20 4:35 p.m., Sagi Grimberg wrote:
>
> > passthru commands are in essence REQ_OP_DRV_IN/REQ_OP_DRV_OUT, which
> > means that the driver shouldn't need the ns at all. So if you have a
> > dedicated request queue (mapped to
On Mon, Jul 20, 2020 at 04:28:26PM -0700, Sagi Grimberg wrote:
> On 7/20/20 4:17 PM, Keith Busch wrote:
> > On Mon, Jul 20, 2020 at 05:01:19PM -0600, Logan Gunthorpe wrote:
> > > On 2020-07-20 4:35 p.m., Sagi Grimberg wrote:
> > >
> > > > passthr
On Sun, Jun 28, 2020 at 06:34:46PM +0800, Baolin Wang wrote:
> Move the sg table allocation and free into the init_request() and
> exit_request(), instead of allocating sg table when queuing requests,
> which can benefit the IO performance.
If you want to pre-allocate something per-request, you ca
On Wed, Jul 29, 2020 at 07:29:08PM +, Lach wrote:
> Hello
>
> I caught a regression in the nvme driver, which shows itself on some
> controllers (In my case, at 126h:2263)
Fix is staged for the next 5.8 pull;
https://git.kernel.dk/cgit/linux-block/commit/?h=block-5.8&id=5bedd3afee8eb01ccd
On Fri, Jul 24, 2020 at 11:25:17AM -0600, Logan Gunthorpe wrote:
> + /*
> + * The passthru NVMe driver may have a limit on the number of segments
> + * which depends on the host's memory fragementation. To solve this,
> + * ensure mdts is limitted to the pages equal to the number
On Fri, Jul 24, 2020 at 11:25:11AM -0600, Logan Gunthorpe wrote:
> This is v16 of the passthru patchset which make a bunch of cleanup as
> suggested by Christoph.
Thank, looks great. Just the comment on 6/9, which probably isn't super
important anyway.
Reviewed-by: Keith Busch
On Wed, Aug 12, 2020 at 03:01:19PM -0600, Logan Gunthorpe wrote:
> @@ -2971,15 +2971,16 @@ int nvme_get_log(struct nvme_ctrl *ctrl, u32 nsid, u8
> log_page, u8 lsp, u8 csi,
> static struct nvme_cel *nvme_find_cel(struct nvme_ctrl *ctrl, u8 csi)
> {
> struct nvme_cel *cel, *ret = NULL;
> +
There's an unrelated whitespace change in nvme_init_identify().
Otherwise, looks fine.
Reviewed-by: Keith Busch
On Fri, Aug 14, 2020 at 03:14:31AM -0400, Tong Zhang wrote:
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index ba725ae47305..c4f1ce0ee1e3 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1249,8 +1249,8 @@ static enum blk_eh_timer_return nvme_timeout
On Fri, Aug 14, 2020 at 11:37:20AM -0400, Tong Zhang wrote:
> On Fri, Aug 14, 2020 at 11:04 AM Keith Busch wrote:
> >
> > On Fri, Aug 14, 2020 at 03:14:31AM -0400, Tong Zhang wrote:
> > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> > > index
: 61f3b8963097 ("nvme-pci: use unsigned for io queue depth")
> Signed-off-by: John Garry
Looks good to me.
Reviewed-by: Keith Busch
On Mon, Aug 24, 2020 at 01:00:11PM -0700, Sagi Grimberg wrote:
> > The way 'spin_lock()' and 'spin_lock_irqsave()' are used is not consistent
> > in this function.
> >
> > Use 'spin_lock_irqsave()' also here, as there is no guarantee that
> > interruptions are disabled at that point, according to
ever demote for memcg reclaim
> mm/numa: new reclaim mode to enable reclaim-based migration
>
> Keith Busch (2):
> mm/migrate: Defer allocating new page until needed
> mm/vmscan: Consider anonymous pages without swap
>
> Yang Shi (1):
>
On Mon, Aug 17, 2020 at 03:50:11PM +0200, Ahmed S. Darwish wrote:
> Hello,
>
> Below v5.9-rc1 commit reliably breaks my boot on a Thinkpad e480
> laptop. PCI nvme detection fails, and the kernel becomes not able
> anymore to find the rootfs / parse "root=".
>
> Bisecting v5.8=>v5.9-rc1 blames tha
On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote:
> a number of customers are requiring the use of normal writes, which we
> want to support.
A device that supports append is completely usable for those customers,
too. There's no need to create divergence in this driver.
On Tue, Aug 18, 2020 at 07:29:12PM +0200, Javier Gonzalez wrote:
> On 18.08.2020 09:58, Keith Busch wrote:
> > On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote:
> > > a number of customers are requiring the use of normal writes, which we
> > > want to supp
: Slot #36 AttnBtn- PwrCtrl- MRL- AttnInd+
> PwrInd+ HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
Acked-by: Keith Busch
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c
> b/drivers/pci/hotplug/pciehp_hpc.c
> index 7dd443aea5a5..2761778f2ecc 100644
> --- a/drivers/pci/h
On Mon, May 06, 2019 at 05:57:52AM -0700, Christoph Hellwig wrote:
> > However, similar to the (1), when the driver will support the devices with
> > hardware based passthrough, it will have to dedicate a bunch of queues to
> > the
> > guest, configure them with the appropriate PASID, and then let
shutdown = true;
> + /* fall through */
> case NVME_CTRL_CONNECTING:
> case NVME_CTRL_RESETTING:
> dev_warn_ratelimited(dev->ctrl.device,
Thanks, Looks good.
Reviewed-by: Keith Busch
On Wed, May 08, 2019 at 01:58:33AM +0900, Akinobu Mita wrote:
> +static void nvme_coredump(struct device *dev)
> +{
> + struct nvme_dev *ndev = dev_get_drvdata(dev);
> +
> + mutex_lock(&ndev->shutdown_lock);
> +
> + nvme_coredump_prologue(ndev);
> + nvme_coredump_epilogue(ndev);
> +
On Tue, May 07, 2019 at 02:31:41PM -0600, Heitke, Kenneth wrote:
> On 5/7/2019 10:58 AM, Akinobu Mita wrote:
> > +
> > +static int nvme_get_telemetry_log_blocks(struct nvme_ctrl *ctrl, void *buf,
> > +size_t bytes, loff_t offset)
> > +{
> > + const size_t chunk
On Thu, May 09, 2019 at 02:59:55AM +0800, Kai-Heng Feng wrote:
> +static int nvme_do_resume_from_idle(struct pci_dev *pdev)
> +{
> + struct nvme_dev *ndev = pci_get_drvdata(pdev);
> + int result;
> +
> + pdev->dev_flags &= ~PCI_DEV_FLAGS_NO_D3;
> + ndev->ctrl.suspend_to_idle = false
migrate_page_move_mapping() doesn't use the mode argument. Remove it
and update callers accordingly.
Signed-off-by: Keith Busch
---
fs/aio.c| 2 +-
fs/f2fs/data.c | 2 +-
fs/iomap.c | 2 +-
fs/ubifs/file.c | 2 +-
include/linux/migrate.h | 3 +-
y: ("Uninitialized pointer read")
> Signed-off-by: Colin Ian King
I would have sworn this was fixed as it's in my tree already, but the
submitted patch sure enough doesn't have it.
I've double checked to see if there are any other discrepencies, and
there
On Tue, May 14, 2019 at 10:04:22AM +0200, Rafael J. Wysocki wrote:
> On Mon, May 13, 2019 at 5:10 PM Keith Busch wrote:
> >
> > On Mon, May 13, 2019 at 03:05:42PM +, mario.limoncie...@dell.com wrote:
> > > This system power state - suspend to idle is going to freeze
siter a memory notifier callback and register the memory attributes
the first time its node is brought online if it wasn't registered.
Signed-off-by: Keith Busch
---
v1 -> v2:
Fixed an unintended __init attribute that generated compiler warnings
(Brice).
drivers/acpi/hma
Instead of registering the hmat cache attributes in line with parsing
the table, save the attributes in the memory target and register them
after parsing completes. This will make it easier to register the
attributes later when hot add is supported.
Signed-off-by: Keith Busch
---
v1 ->
On Thu, May 09, 2019 at 02:12:55AM -0700, Stefan Hajnoczi wrote:
> On Mon, May 06, 2019 at 12:04:06PM +0300, Maxim Levitsky wrote:
> > On top of that, it is expected that newer hardware will support the PASID
> > based
> > device subdivision, which will allow us to _directly_ pass through the
> >
r the series:
Reviewed-by: Keith Busch
On Thu, May 09, 2019 at 03:28:32AM -0700, Kai-Heng Feng wrote:
> at 17:56, Christoph Hellwig wrote:
> > The we have the sequence in your patch. This seems to be related to
> > some of the MS wording, but I'm not sure what for example tearing down
> > the queues buys us. Can you explain a bit mor
On Thu, May 09, 2019 at 06:57:34PM +, mario.limoncie...@dell.com wrote:
> No, current Windows versions don't transition to D3 with inbox NVME driver.
> You're correct, it's explicit state transitions even if APST was enabled
> (as this patch is currently doing as well).
The proposed patch does
On Thu, May 09, 2019 at 10:54:04PM +0200, Rafael J. Wysocki wrote:
> On Thu, May 9, 2019 at 9:33 PM Keith Busch wrote:
> > #include
> > @@ -2851,6 +2852,8 @@ static int nvme_suspend(struct device *dev)
> > struct pci_dev *pdev = to_pci_dev(dev);
> >
On Thu, May 09, 2019 at 09:37:58PM +, mario.limoncie...@dell.com wrote:
> > +int nvme_set_power(struct nvme_ctrl *ctrl, unsigned npss)
> > +{
> > + int ret;
> > +
> > + mutex_lock(&ctrl->scan_lock);
> > + nvme_start_freeze(ctrl);
> > + nvme_wait_freeze(ctrl);
> > + ret = nvme_set_feat
On Thu, May 09, 2019 at 10:30:52PM -0700, Christoph Hellwig wrote:
> Also I don't see any reason why we'd need to do the freeze game on
> resume.
Right, definitely no reason for resume.
> Even on suspend it looks a little odd to me, as in theory
> the PM core should have already put the system
On Fri, May 10, 2019 at 01:23:11AM -0700, Rafael J. Wysocki wrote:
> On Fri, May 10, 2019 at 8:08 AM Kai-Heng Feng
> > I tested the patch from Keith and it has two issues just as simply skipping
> > nvme_dev_disable():
> > 1) It consumes more power in S2I
> > 2) System freeze after resume
>
> Well
On Thu, May 09, 2019 at 11:05:42PM -0700, Kai-Heng Feng wrote:
> Yes, that’ what I was told by the NVMe vendor, so all I know is to impose a
> memory barrier.
> If mb() shouldn’t be used here, what’s the correct variant to use in this
> context?
I'm afraid the requirement is still not clear to
On Fri, May 10, 2019 at 11:15:05PM +0800, Kai Heng Feng wrote:
> Sorry, I should mention that I use a slightly modified
> drivers/nvme/host/pci.c:
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 3e4fb891a95a..ece428ce6876 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/d
Feng
Signed-off-by: Keith Busch
---
Disclaimer: I've tested only on emulation faking support for the feature.
General question: different devices potentially have divergent values
for power consumption and transition latencies. Would it be useful to
allow a user tunable setting to select the desi
On Sat, May 11, 2019 at 12:22:58AM -0700, Christoph Hellwig wrote:
> A couple nitpicks, mostly leftover from the previous iteration
> (I didn't see replies to those comments from you, despite seeing
> a reply to my mail, assuming it didn't get lost):
I thought you just meant the freeze/unfreeze se
On Sat, May 11, 2019 at 11:06:35PM -0700, Chaitanya Kulkarni wrote:
> On 5/10/19 2:35 PM, Keith Busch wrote:
> >
> > +int nvme_set_power(struct nvme_ctrl *ctrl, unsigned ps)
> dev->ctrl.npss is u8 can we use same data type here ?
> If this is due to last_ps we use a
On Sun, May 12, 2019 at 08:54:15AM -0700, Akinobu Mita wrote:
> +static void nvme_coredump_logs(struct nvme_dev *dev)
> +{
> + struct dev_coredumpm_bulk_data *bulk_data;
> +
> + if (!dev->dumps)
> + return;
> +
> + bulk_data = nvme_coredump_alloc(dev, 1);
> + if (!bulk_d
On Sun, May 12, 2019 at 08:54:16AM -0700, Akinobu Mita wrote:
> @@ -2536,6 +2539,9 @@ static void nvme_reset_work(struct work_struct *work)
> if (result)
> goto out;
>
> + nvme_coredump_logs(dev);
If you change nvme_coredump_logs to return an int, check it here for < 0
an
On Mon, May 13, 2019 at 02:24:41PM +, mario.limoncie...@dell.com wrote:
> This was not a disk with HMB, but with regard to the HMB I believe it needs
> to be
> removed during s0ix so that there isn't any mistake that SSD thinks it can
> access HMB
> memory in s0ix.
Is that really the case, t
On Mon, May 13, 2019 at 02:43:43PM +, mario.limoncie...@dell.com wrote:
> > Well, it sounds like your partners device does not work properly in this
> > case. There is nothing in the NVMe spec that says queues should be
> > torn down for deep power states, and that whole idea seems rather
> >
On Mon, May 13, 2019 at 03:05:42PM +, mario.limoncie...@dell.com wrote:
> This system power state - suspend to idle is going to freeze threads.
> But we're talking a multi threaded kernel. Can't there be a timing problem
> going
> on then too? With a disk flush being active in one task and t
On Mon, May 13, 2019 at 04:57:08PM +0200, Christoph Hellwig wrote:
> On Mon, May 13, 2019 at 02:54:49PM +, mario.limoncie...@dell.com wrote:
> > And NVME spec made it sound to me that while in a low power state it
> > shouldn't
> > be available if the memory isn't available.
> >
> > NVME spec
On Tue, May 14, 2019 at 01:16:22AM +0800, Kai-Heng Feng wrote:
> Disabling HMB prior suspend makes my original patch work without memory
> barrier.
>
> However, using the same trick on this patch still freezes the system during
> S2I.
Could you post your code, please?
On Thu, May 02, 2019 at 05:59:17PM +0900, Akinobu Mita wrote:
> This enables to capture snapshot of controller information via device
> coredump machanism, and it helps diagnose and debug issues.
>
> The nvme device coredump is triggered before resetting the controller
> caused by I/O timeout, and
On Fri, May 03, 2019 at 12:20:17AM +0300, Maxim Levitsky wrote:
> On Thu, 2019-05-02 at 15:12 -0600, Heitke, Kenneth wrote:
> > On 5/2/2019 5:47 AM, Maxim Levitsky wrote:
> > > +static void nvme_ext_queue_free(struct nvme_ctrl *ctrl, u16 qid)
> > > +{
> > > + struct nvme_dev *dev = to_nvme_dev(ctrl
On Fri, May 03, 2019 at 12:38:08PM +0900, Akinobu Mita wrote:
> 2019年5月2日(木) 22:03 Keith Busch :
> > On Thu, May 02, 2019 at 05:59:17PM +0900, Akinobu Mita wrote:
> > > This enables to capture snapshot of controller information via device
> > > coredump machanism, and
On Thu, May 02, 2019 at 08:59:39PM -0700, Frederick Lawler wrote:
> +#define dev_fmt(fmt) "DPC: " fmt
> +
> @@ -110,7 +111,7 @@ static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
> + pci_warn(pdev, "DPC root port still busy\n");
> @@ -229,18 +229,17 @@ static irqreturn_t dpc_handler
added lock, ensuring onlining multiple regions
is single threaded to prevent duplicate hmat registration races.
Keith Busch (2):
hmat: Register memory-side cache after parsing
hmat: Register attributes for memory hot add
drivers/acpi/hmat/hmat.c
Instead of registering the hmat cache attributes in line with parsing
the table, save the attributes in the memory target and register them
after parsing completes. This will make it easier to register the
attributes later when hot add is supported.
Signed-off-by: Keith Busch
---
drivers/acpi
and register the memory attributes
the first time its node is brought online if it wasn't registered,
ensuring a node's attributes may be registered only once.
Reported-by: Brice Goglin
Signed-off-by: Keith Busch
---
drivers/acpi/hmat/hmat.c | 72 -
On Wed, Mar 20, 2019 at 06:30:29PM +0200, Maxim Levitsky wrote:
> Or instead I can use the block backend,
> (but note that currently the block back-end doesn't support polling which is
> critical for the performance).
Oh, I think you can do polling through there. For reference, fs/io_uring.c
has
On Thu, Mar 21, 2019 at 04:12:39PM +, Stefan Hajnoczi wrote:
> mdev-nvme seems like a duplication of SPDK. The performance is not
> better and the features are more limited, so why focus on this approach?
>
> One argument might be that the kernel NVMe subsystem wants to offer this
> functiona
Refactor unmap_and_move() handling for the new page into a separate
function from locking and preparing the old page.
No functional change here: this is just making it easier to reuse this
part of the page migration from contexts that already locked the old page.
Signed-off-by: Keith Busch
Trace the source and destination node of a page migration to help debug
memory usage.
Signed-off-by: Keith Busch
---
include/trace/events/migrate.h | 26 ++
mm/migrate.c | 1 +
2 files changed, 27 insertions(+)
diff --git a/include/trace/events
On Thu, Mar 28, 2019 at 02:59:30PM -0700, Yang Shi wrote:
> Yes, it still could fail. I can't tell which way is better for now. I
> just thought scanning another round then migrating should be still
> faster than swapping off the top of my head.
I think it depends on the relative capacities betw
On Fri, Mar 29, 2019 at 02:15:03PM -0700, Dan Williams wrote:
> On Mon, Mar 11, 2019 at 1:55 PM Keith Busch wrote:
> > +static __init struct memory_target *find_mem_target(unsigned int mem_pxm)
> > +{
> > + struct memory_target *target;
> > +
> > + lis
On Tue, Jul 30, 2019 at 03:45:31AM -0700, Rafael J. Wysocki wrote:
> So I can reproduce this problem with plain 5.3-rc1 and the patch below fixes
> it.
>
> Also Mario reports that the same patch needs to be applied for his 9380 to
> reach
> SLP_S0 after some additional changes under testing/revi
801 - 900 of 931 matches
Mail list logo
