linux-kernel - RE: [PATCH] PM: Enable asynchronous noirq resume threads to save the resuming time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jan 2014 00:35:16 +0000
From:	"Liu, Chuansheng" <chuansheng.liu@...el.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"Brown, Len" <len.brown@...el.com>, "pavel@....cz" <pavel@....cz>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Li, Zhuangzhi" <zhuangzhi.li@...el.com>
Subject: RE: [PATCH] PM: Enable asynchronous noirq resume threads to save
 the resuming time

Hello Rafael,

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@...ysocki.net]
> Sent: Wednesday, January 15, 2014 6:55 AM
> To: Liu, Chuansheng
> Cc: gregkh@...uxfoundation.org; Brown, Len; pavel@....cz;
> linux-pm@...r.kernel.org; linux-kernel@...r.kernel.org; Li, Zhuangzhi
> Subject: Re: [PATCH] PM: Enable asynchronous noirq resume threads to save
> the resuming time
> 
> On Tuesday, January 14, 2014 03:18:08 PM Chuansheng Liu wrote:
> >
> > Currently, the dpm_resume_noirq() is done synchronously, and for PCI devices
> > pci_pm_resume_noirq():
> >
> > pci_pm_resume_noirq()
> >  pci_pm_default_resume_early()
> >   pci_power_up()
> >    pci_raw_set_power_state()
> > Which set the device from D3hot to D0 mostly, for every device, there will
> > be one 10ms(pci_pm_d3_delay) to wait.
> >
> > Hence normally dpm_resume_noirq() will cost > 100ms, which is bigger for
> mobile
> > platform.
> 
> pci_pm_d3_delay usually is not 10 ms.  What is 10 ms is dev->d3_delay, but
> that also is not on every platform now.
Yes, it is d3_delay exactly, thanks your correction.

> 
> That said the approach here makes sense, but I have two questions:
> 
> 1. On what systems has it been tested?
I have been tested on Baytrail platform, and at the beginning the d3_delay is set to 0,
but we really meet the HANG issue if we operate the device immediately sometimes,
so currently most PCI devices in Baytrail has the 10ms delay.
And it caused the whole resume time bigger than Clovertrail platform;

> 2. What about suspend_late/resume_early?  If the _noirq things are to be
> executed asynchronously, those should be too.
I noticed it just taken little time often, and I cannot find out some reasons for changing them
in theory, so if you like it, I will update them into patch V2 also:)