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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux