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]
Message-ID: <27240C0AC20F114CBF8149A2696CBE4A01C02047@SHSMSX101.ccr.corp.intel.com>
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:)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ