[collapsing both of your replies]
Dear Damien,
Am 23.03.22 um 10:39 schrieb Damien Le Moal:
On 3/23/22 17:43, Paul Menzel wrote:
Am 23.03.22 um 09:17 schrieb Damien Le Moal:
This series removes the long link debounce delays by default for all
adapters, except for those known to require these delays
(e.g. ata_piix).
Is it know, or just a theory?
The first 2 patches are code cleanup improving the interface of several
functions handling delays.
Patch 3 removes the long delay in sata_link_resume() and reverses the
link flag ATA_LFLAG_NO_DEBOUNCE_DELAY to ATA_LFLAG_DEBOUNCE_DELAY for
adapters to request the delay if needed.
Patch 4 improves sata_link_debounce() by shortening the link stability
test, unless the link has the ATA_LFLAG_DEBOUNCE_DELAY flag set.
This series was tested on a machine with 2 AHCI adapters (Intel and
Marvell) with a port-multiplier box attached to cover that case too.
It’d be great if you gave an example benchmark.
No need for a benchmark. This is not hot path stuff. This code runs only
during device discovery on boot and on resume after suspend.
So apply the patches and reboot, check dmesg if you see errors or not and
if your disks are all there. Same after a suspend+resume.
Yes, I know what I need to check. I meant, that you write without this
patchset my system with HBA controller X and 32 [vendor/model] disks
attached reaches the message Y in Z1 seconds, and with the series Z2
seconds.
Comments and lots of testing are welcome !
Damien Le Moal (4):
ata: libata-sata: Simplify sata_link_resume() interface
ata: libata-sata: Introduce struct sata_deb_timing
ata: libata-sata: Remove debounce delay by default
ata: libata-sata: Improve sata_link_debounce()
[…]
I am wondering how sure we can be, there won’t be any regressions? Not
having the boot disk detected is quite a serious issue/regression, and
it should be made easy for users to fix that without having to rebuild
the Linux kernel. A Linux kernel CLI parameter to enable the delay would
be helpful for effected users.
I am working on another series for that. The patches will allow
controlling most horkage and link flags on/off using libata.force kernel
boot parameter. That will allow figuring out problems without patching in
the field, for patches to be later added.
Sounds good. But this needs to be available before the changes at hand,
doesn’t it?
I do not think we need to have the flexibility of changing the debounce
delay. The 200ms delay is already arbitrary. There is no reliable way of
figuring out the ideal short delay. So havin "on" (default patch applied),
and "off" (delay added like before) is enough I think.
Yes, I was only talking about on/off. (You probably thought, I was
referring to the mechanism I tried to implement in my RFC series.)
Kind regards,
Paul
