You're right, staggered spinup is not enforced today when the disks are behind several ATA ports. Only the disks behind a port multiplier are spun up one at a time. We are currently waiting for all the device(s) on the slowest port to resume to continue. Gwendal. On Tue, Jan 14, 2014 at 1:45 PM, Todd E Brandt <todd.e.brandt@xxxxxxxxxxxxxxx> wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
