Re: [PATCH/RESEND v2 0/2] Hard disk S3 resume time optimization

[Todd E Brandt <todd.e.brandt@linux.intel.com>]

On Tue, Jan 14, 2014 at 09:43:25AM -0500, Tejun Heo wrote:
> Hello, Gwendal.
> 
> On Mon, Jan 13, 2014 at 04:36:52PM -0800, Gwendal Grignou wrote:
> > Won't this patch defeat staggered spinup at resume? If you have a jbod
> > with a smallish power supply, with a 12V rail designed for the steady
> > state and 1 or 2 devices spinning up at once, you may be in trouble
> > when all the disks will want to spinup in same second.
> 
> Yeah, I think it would.  We never fully solved the staggered spinup
> problem and it probably is too late to invest into proper mechanism
> for that.  I think an easy workaround would be, say, have a kernel
> param which limits the max number of concurrent async wakeups and set
> the value to something reasonable - say, 2, which should give us most
> of benefits of async wakeup in vast majority of cases while avoiding
> blowing up PSUs on larger setups.

Does my patch actually have any affect on staggered spinup? I see that when
the HOST_CAP_SSS flag is detected it causes a PORT_CMD_SPIN_UP to be issued
during each port's resume. But the port resume calls themselves appear to
always be asynchronous, regardless of my patch's changes. (The ata_port
devices all have their power.async_suspend flags set, so the dpm_resume
call issues them all in parallel) So as far as I can tell I don't think 
I'm causing any harm.

I do see how my patch might hinder future attempts at staggered resume
handling, since it would effectively render the power.async_suspend flag
useless. Would it be wise for ata_port_resume to check the ata_port's 
power.async_suspend flag and only use asynchronous ata_port_request_pm 
if it's enabled?

> 
> Thanks.
> 
> -- 
> tejun