On 3/23/22 19:59, Paul Menzel wrote: >>> 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. There is going to be too much variation from machine to machine as that depends on the adapter & devices used for testing. The only sensible thing to do is to compare timing before patching with timing after patching and see if there are some gains. On my test rig, I have so many drives and various HBAs connected that the boot time gains overall are nil. But I do see faster per-ata drive scan times. > >>>> 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? Not really. For now, we need to check if these patches break anything, regardless of the libata.force changes. I consider libata.force for field debugging. A user should not have to use it to get a system running. The kernel should have sensible defaults for that and things should run out of the box without the need for additional kernel boot parameters. -- Damien Le Moal Western Digital Research
