ahci: CAP_SSS and parallel scan
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.
Signature · 1 line
tejun
Quoted 9 lines · 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_SSSdisabling parallel scan. The code was added by Arjan in commit886ad09fc83342aa1c5a02a0b6d3298b78a8067f. 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).
Hello,
Quoted 3 lines · Arjan van de Ven
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.
Quoted 3 lines
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.
Signature · 1 line
tejun
Quoted 17 lines · Tejun Heo
Hello,
Quoted 3 lines · Arjan van de Ven
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.
Quoted 3 lines
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).
Quoted 8 lines
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
Hello,
Quoted 7 lines · Jeff Garzik
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.
Signature · 1 line
tejun
Quoted 11 lines · Tejun Heo
Hello,
Quoted 7 lines · Jeff Garzik
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.
Quoted 6 lines
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
Quoted 2 lines · Jeff Garzik
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.
Quoted 2 lines
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.
Signature · 1 line
tejun
Quoted 6 lines · Tejun Heo
Quoted 2 lines · Jeff Garzik
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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 3 lines · Jeff Garzik
Quoted 3 lines
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
Quoted 7 lines · Mark Lord
Quoted 3 lines · Jeff Garzik
Quoted 3 lines
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. :-)
Signature · 1 line
tejun