Re: [PATCH 0/4] Remove link debounce delays by default

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

 



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




[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux