Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
IronPort-SDR: /iKMhND9sYPUgzy06HH4V7AtQq/Ev7LQeS5gyxpUXrX9QFN1wRIppWC3UzW6xRPygJAPBilL1p
 UbWeqMdt92MC8OCU/DOFL2XKEkcWXNKhZvs7rvhttH9hodctdIGGLMBHxyo9uDPd6pM72nKAAo
 843odqY6wQRAGXzarWnWX2vA5eg23p+/XBXRY8LSx+vJjKNUpujY6XYhW/AKeZ/31gXPT3AKNd
 kZsOvqhmBCa98ysmxeaG60NHWmDWtVOU2QRqK8waD8L30zONrmcq0+/mcP4sCsxyOOH4B2hLOJ
 xRBYjx13k0LNkXMpShMk1Z1w
IronPort-SDR: Di/cOSpedOtA05HAeag1i7AfoO2WvLUorSi7eosChl3lm8rUvk1KIfMwAIEpAk3RdEczsQL/Sr
 WZeZ+jVJXFzVtY+YrsjprqTXsP/t42TGuWjbt+6OgNVtFPwtr1WmrxsLb3g3v9q0aZ+fEyaKcZ
 VUhy2gYqFs0l4HesMnvsKI/Wy2T8KidbAqxdUDMBwE4mMc+28TUiO9Ho9ai6zkCwKsZXOlF4TX
 0KJYNrBgJG5qAFnZF9Fmr8PXSGuHY0EbDLFcR88VB6IdO5ybsY9qZUtHVATEMyytdFYdVFOu3d
 RJ0=
WDCIronportException: Internal
Message-ID: <b082ed3f-e2de-450f-acc6-9508d7689290@opensource.wdc.com>
Date:   Wed, 10 Aug 2022 06:57:55 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.12.0
Subject: Re: [ata] 0568e61225: stress-ng.copy-file.ops_per_sec -15.0%
 regression
Content-Language: en-US
To:     David Laight <David.Laight@ACULAB.COM>,
        John Garry <john.garry@huawei.com>,
        kernel test robot <oliver.sang@intel.com>
Cc:     Christoph Hellwig <hch@lst.de>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux Memory Management List <linux-mm@kvack.org>,
        "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
        "lkp@lists.01.org" <lkp@lists.01.org>,
        "lkp@intel.com" <lkp@intel.com>,
        "ying.huang@intel.com" <ying.huang@intel.com>,
        "feng.tang@intel.com" <feng.tang@intel.com>,
        "zhengjun.xing@linux.intel.com" <zhengjun.xing@linux.intel.com>,
        "fengwei.yin@intel.com" <fengwei.yin@intel.com>
References: <YuzPMMnnY739Tnit@xsang-OptiPlex-9020>
 <1f498d4a-f93f-ceb4-b713-753196e5e08d@opensource.wdc.com>
 <3451fa5a-6229-073f-ae18-0c232cd48ed5@huawei.com>
 <e4106ffa-3842-45c0-9756-5226cfcfa17d@opensource.wdc.com>
 <c4b45c0e06af473abe17e3471e1bb948@AcuMS.aculab.com>
From:   Damien Le Moal <damien.lemoal@opensource.wdc.com>
Organization: Western Digital Research
In-Reply-To: <c4b45c0e06af473abe17e3471e1bb948@AcuMS.aculab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2022/08/09 8:16, David Laight wrote:
> ...
>>>> Without knowing what the device adapter is, hard to say where the problem is. I
>>>> suspect that with the patch applied, we may be ending up with a small default
>>>> max_sectors value, causing overhead due to more commands than necessary.
>>>>
>>>> Will check what I see with my test rig.
>>>
>>> As far as I can see, this patch should not make a difference unless the
>>> ATA shost driver is setting the max_sectors value unnecessarily low.
>>
>> That is my hunch too, hence my question about which host driver is being used
>> for this test... That is not apparent from the problem report.
> 
> No one's fallen over the old problem and managed to limit
> the number of sectors in a read to the number of sectors
> in (IIRC) a 'multi sector' read that uses a single DMA burst?
> 
> Was always a good way of killing disk performance.
> 
> IIRC the maximum number of sectors for an ATA disk transfer is 255.

That is for super old pata/ide devices. Modern SATA/AHCI disks can do a lot more
than that with NCQ/DMA. The default max_sectors_kb for AHCI connected devices is
1280 KB = 2560 sectors, max_segments = 168 and max_segment_size = 65536 B, which
gives a reliable command size of at least 168 * 4096 = 688128 B (1344 sectors)
with 4KB page size architectures.

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)


-- 
Damien Le Moal
Western Digital Research