ahci: CAP_SSS and parallel scan

ahci: CAP_SSS and parallel scan

[Tejun Heo]

Hello,

Artem reported on bko#15918 that on his machine ahci probing takes too
long (well, if you ask me, that's not too long but anyways).  This is
caused by CAP_SSS disabling parallel scan.  The code was added by
Arjan in commit 886ad09fc83342aa1c5a02a0b6d3298b78a8067f.  There is a
module parameter to skip this but I'm curious whether the change was
based on an actual problem as on most PC hardware by the time ahci
driver kick in, the BIOS has spun up everything already.

Thanks.

-- 
tejun

Re: ahci: CAP_SSS and parallel scan

[Arjan van de Ven]

On 5/6/2010 1:22, Tejun Heo wrote:
> Hello,
>
> Artem reported on bko#15918 that on his machine ahci probing takes too
> long (well, if you ask me, that's not too long but anyways).  This is
> caused by CAP_SSS disabling parallel scan.  The code was added by
> Arjan in commit 886ad09fc83342aa1c5a02a0b6d3298b78a8067f.  There is a
> module parameter to skip this but I'm curious whether the change was
> based on an actual problem as on most PC hardware by the time ahci
> driver kick in, the BIOS has spun up everything already.

This was based on Jeff's review comments on an earlier patch that did not use SSS.

The thing is, SSS means the system requests (well, demands) that we don't spin up the disks
up in parallel.... which we really really ought to honor... Jeff had a very valid point.

While today some bioses may spin everything up, that's not going to be the case going forward...
the industry as a whole is moving away from that (slowly but steadily).

Re: ahci: CAP_SSS and parallel scan

[Tejun Heo]

Hello,

On 05/06/2010 11:30 AM, Arjan van de Ven wrote:
> The thing is, SSS means the system requests (well, demands) that we
> don't spin up the disks up in parallel.... which we really really
> ought to honor... Jeff had a very valid point.

Hmmm... yeah but SSS doesn't really demand it.  It just says "I can do
staggered spin up".  I wish this thing had been implemented in the
form of "stay spin down till necessary (ie. start in standby mode)".
Currently, there's no way to tell whether staggered spin up is needed
or drives are already spun up.

> While today some bioses may spin everything up, that's not going to
> be the case going forward...  the industry as a whole is moving away
> from that (slowly but steadily).

Yeah, sure, in the long run maybe but I'm skeptical how useful this is
at this point.  Going forward, the right thing to do would be
implementing some sort of token infrastructure so that drivers can
request and hold the token while spinning up a drive so that the
concurrency of spin ups can be controlled.

Jeff, what do you think about lifting the check for now unless there
are known cases where this can cause problems?

Thanks.

-- 
tejun

Re: ahci: CAP_SSS and parallel scan

[Jeff Garzik]

On 05/06/2010 10:44 AM, Tejun Heo wrote:
> Hello,
>
> On 05/06/2010 11:30 AM, Arjan van de Ven wrote:
>> The thing is, SSS means the system requests (well, demands) that we
>> don't spin up the disks up in parallel.... which we really really
>> ought to honor... Jeff had a very valid point.
>
> Hmmm... yeah but SSS doesn't really demand it.  It just says "I can do
> staggered spin up".  I wish this thing had been implemented in the
> form of "stay spin down till necessary (ie. start in standby mode)".
> Currently, there's no way to tell whether staggered spin up is needed
> or drives are already spun up.
>
>> While today some bioses may spin everything up, that's not going to
>> be the case going forward...  the industry as a whole is moving away
>> from that (slowly but steadily).
>
> Yeah, sure, in the long run maybe but I'm skeptical how useful this is
> at this point.  Going forward, the right thing to do would be
> implementing some sort of token infrastructure so that drivers can
> request and hold the token while spinning up a drive so that the
> concurrency of spin ups can be controlled.
>
> Jeff, what do you think about lifting the check for now unless there
> are known cases where this can cause problems?

The problem being...  that we are honoring SSS bit, and thus thing are 
slower?  :)  I don't see any reason to change that, seeing as how people 
may be using it to avoid power spikes.

I agree there's no way to tell whether SSS is needed, but we cannot 
ignore SSS on that basis alone.  We should avoid making the assumption 
that BIOS w/ SSS bit has already spun up all drives regardless.

	Jeff

Re: ahci: CAP_SSS and parallel scan

[Tejun Heo]

Hello,

On 05/06/2010 09:49 PM, Jeff Garzik wrote:
> The problem being...  that we are honoring SSS bit, and thus thing are
> slower?  :)  I don't see any reason to change that, seeing as how people
> may be using it to avoid power spikes.
> 
> I agree there's no way to tell whether SSS is needed, but we cannot
> ignore SSS on that basis alone.  We should avoid making the assumption
> that BIOS w/ SSS bit has already spun up all drives regardless.

It's just that the usefulness seems very limited at this point so it
might be better idea to flip the default behavior and let people opt
in for SSS.  The problem is compounded by the complete serial behavior
we end up with and on some machines large number of ahci ports.  I
don't care much about boot time all that much but as that seems to be
a hot issue on desktops too these days.

Thanks.

-- 
tejun

Re: ahci: CAP_SSS and parallel scan

[Jeff Garzik]

On 05/07/2010 01:14 AM, Tejun Heo wrote:
> Hello,
>
> On 05/06/2010 09:49 PM, Jeff Garzik wrote:
>> The problem being...  that we are honoring SSS bit, and thus thing are
>> slower?  :)  I don't see any reason to change that, seeing as how people
>> may be using it to avoid power spikes.
>>
>> I agree there's no way to tell whether SSS is needed, but we cannot
>> ignore SSS on that basis alone.  We should avoid making the assumption
>> that BIOS w/ SSS bit has already spun up all drives regardless.
>
> It's just that the usefulness seems very limited at this point so it
> might be better idea to flip the default behavior and let people opt
> in for SSS.  The problem is compounded by the complete serial behavior
> we end up with and on some machines large number of ahci ports.  I
> don't care much about boot time all that much but as that seems to be
> a hot issue on desktops too these days.

I'm not sure the usefulness is limited, as it definitely avoids power 
spikes on server BIOSen that care.

Also, it seems unwise for the Linux SATA driver to do the exact 
-opposite- of what the SSS bit intends, by default.

The existing ignore_sss option should be sufficient for people who wish 
to entertain non-standard behavior...

	Jeff

Re: ahci: CAP_SSS and parallel scan

[Tejun Heo]

On 05/07/2010 11:33 PM, Jeff Garzik wrote:
> I'm not sure the usefulness is limited, as it definitely avoids power
> spikes on server BIOSen that care.

So, are there actually machines which get affected by this?  In that
case, sure, the current behavior is the right one.

> Also, it seems unwise for the Linux SATA driver to do the exact
> -opposite- of what the SSS bit intends, by default.

Yeah, well, the thing is that SSS in itself doesn't really indicate
need for staggered spin up.  It just says it knows how to.

Thanks.

-- 
tejun

Re: ahci: CAP_SSS and parallel scan

[Jeff Garzik]

On 05/08/2010 04:40 AM, Tejun Heo wrote:
> On 05/07/2010 11:33 PM, Jeff Garzik wrote:
>> I'm not sure the usefulness is limited, as it definitely avoids power
>> spikes on server BIOSen that care.
>
> So, are there actually machines which get affected by this?  In that
> case, sure, the current behavior is the right one.

The current behavior is the safe, conservative interpretation.  The 
alternative is risking unwanted power spikes for the sake of boot speed.

I would set a high barrier for taking that risk:  polling multiple 
hardware vendors about in-the-field SSS usage.


>> Also, it seems unwise for the Linux SATA driver to do the exact
>> -opposite- of what the SSS bit intends, by default.
>
> Yeah, well, the thing is that SSS in itself doesn't really indicate
> need for staggered spin up.  It just says it knows how to.

A valid point, I agree.  But absent any other method of communicating 
that SSS behavior is desired, activating staggered spin-up based on SSS 
is the only logical interpretation, AFAICS.  SSS bit set implies SSS 
-might- be needed.  If SSS might be needed, then one must stagger 
spin-up or risk failing to meet the requirement.  !SSS is the only case 
where you are -guaranteed- not to need staggered spin-up.

	Jeff

Re: ahci: CAP_SSS and parallel scan

[Mark Lord]

On 06/05/10 03:49 PM, Jeff Garzik wrote:
>
>> Currently, there's no way to tell whether staggered spin up is needed
>> or drives are already spun up.

Perhaps by issuing a "CHECK POWER MODE" command?
For many drives, a non-spinning drive is detectable from its IDENTIFY data.

Cheers

Re: ahci: CAP_SSS and parallel scan

[Tejun Heo]

On 05/06/2010 10:19 PM, Mark Lord wrote:
> On 06/05/10 03:49 PM, Jeff Garzik wrote:
>>
>>> Currently, there's no way to tell whether staggered spin up is needed
>>> or drives are already spun up.
> 
> Perhaps by issuing a "CHECK POWER MODE" command?
> For many drives, a non-spinning drive is detectable from its IDENTIFY data.

Heh, yeah, I wish it were like that.  IIRC, there are two different
staggered spin up scheme.  The one implemented by CAP_SSS uses link
init sequence as signal to spin up which means you don't even know
whether there's a device attached before committing to spinning it up.
Gotta love ATA.  :-)

-- 
tejun