Messages in this thread | | | From | <> | Subject | RE: [Regression] Commit "nvme/pci: Use host managed power state for suspend" has problems | Date | Thu, 25 Jul 2019 19:09:25 +0000 |
| |
> -----Original Message----- > From: Kai-Heng Feng <kai.heng.feng@canonical.com> > Sent: Thursday, July 25, 2019 1:20 PM > To: Rafael J. Wysocki > Cc: Limonciello, Mario; Rafael J. Wysocki; Keith Busch; Christoph Hellwig; Sagi > Grimberg; linux-nvme; Linux PM; Linux Kernel Mailing List; Rajat Jain > Subject: Re: [Regression] Commit "nvme/pci: Use host managed power state for > suspend" has problems > > > [EXTERNAL EMAIL] > > at 01:03, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > On Thu, Jul 25, 2019 at 6:24 PM <Mario.Limonciello@dell.com> wrote: > >> +Rajat > >> > >>> -----Original Message----- > >>> From: Kai-Heng Feng <kai.heng.feng@canonical.com> > >>> Sent: Thursday, July 25, 2019 9:03 AM > >>> To: Rafael J. Wysocki > >>> Cc: Keith Busch; Christoph Hellwig; Sagi Grimberg; linux- > >>> nvme@lists.infradead.org; Limonciello, Mario; Linux PM; LKML > >>> Subject: Re: [Regression] Commit "nvme/pci: Use host managed power > >>> state for > >>> suspend" has problems > >>> > >>> > >>> [EXTERNAL EMAIL] > >>> > >>> Hi Rafael, > >>> > >>> at 17:51, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > >>> > >>>> Hi Keith, > >>>> > >>>> Unfortunately, > >>>> > >>>> commit d916b1be94b6dc8d293abed2451f3062f6af7551 > >>>> Author: Keith Busch <keith.busch@intel.com> > >>>> Date: Thu May 23 09:27:35 2019 -0600 > >>>> > >>>> nvme-pci: use host managed power state for suspend > >>>> > >>>> doesn't universally improve things. In fact, in some cases it makes > >>>> things worse. > >>>> > >>>> For example, on the Dell XPS13 9380 I have here it prevents the > >>>> processor > >>>> package > >>>> from reaching idle states deeper than PC2 in suspend-to-idle (which, of > >>>> course, also > >>>> prevents the SoC from reaching any kind of S0ix). > >>>> > >>>> That can be readily explained too. Namely, with the commit above the > >>>> NVMe device > >>>> stays in D0 over suspend/resume, so the root port it is connected to > >>>> also > >>>> has to stay in > >>>> D0 and that "blocks" package C-states deeper than PC2. > >>>> > >>>> In order for the root port to be able to go to D3, the device connected > >>>> to it also needs > >>>> to go into D3, so it looks like (at least on this particular machine, > >>>> but > >>>> maybe in > >>>> general), both D3 and the NVMe-specific PM are needed. > >> > >> Well this is really unfortunate to hear. I recall that with some disks > >> we were > >> seeing problems where NVME specific PM wasn't working when the disk was > >> in D3. > >> > >> On your specific disk, it would be good to know if just removing the > >> pci_save_state(pdev) > >> call helps. > > > > Yes, it does help. > > > >> If so, : > >> * that might be a better option to add as a parameter. > >> * maybe we should double check all the disks one more time with that > >> tweak. > > > > At this point it seems so. > > > >>>> I'm not sure what to do here, because evidently there are systems where > >>>> that commit > >>>> helps. I was thinking about adding a module option allowing the user to > >>>> override the > >>>> default behavior which in turn should be compatible with 5.2 and earlier > >>>> kernels. > >>> > >>> I just briefly tested s2i on XPS 9370, and the power meter shows a > >>> 0.8~0.9W > >>> power consumption so at least I don’t see the issue on XPS 9370. > >> > >> To me that confirms NVME is down, but it still seems higher than I would > >> have > >> expected. We should be more typically in the order of ~0.3W I think. > > From what I’ve observed, ~0.8W s2idle is already better than Windows (~1W). > 0.3W is what I see during S5.
Oh thanks for confirming, I'm probably mixing up with another system.
> > > > > It may go to PC10, but not reach S0ix. > > > > Anyway, I run the s2idle tests under turbostat which then tells me > > what has happened more precisely. > > The XPS 9370 at my hand does reach to s0ix during s2idle: > # cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec > 15998400 > > So I think keep the root port in D0 is not the culprit here. > Maybe something is wrong on the ASPM settings? > > Kai-Heng
I have a 9380 on hand and I'm also showing slps0 residency with the SSD in it and this series (Hynix BC501).
| |