From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6CDAC25B0E for ; Tue, 16 Aug 2022 15:42:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEFBB6B0075; Tue, 16 Aug 2022 11:42:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9F8B6B0078; Tue, 16 Aug 2022 11:42:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B409C8D0001; Tue, 16 Aug 2022 11:42:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A1C496B0075 for ; Tue, 16 Aug 2022 11:42:48 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 717B8120886 for ; Tue, 16 Aug 2022 15:42:48 +0000 (UTC) X-FDA: 79805873616.01.2880B80 Received: from esa1.hgst.iphmx.com (esa1.hgst.iphmx.com [68.232.141.245]) by imf02.hostedemail.com (Postfix) with ESMTP id 1113680035 for ; Tue, 16 Aug 2022 15:42:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1660664567; x=1692200567; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=4pLJV4ar6F2DZGfMkGTvI6mAYr0kU7DMXxSq+tx3CnI=; b=hmcVktkknlPWjBOgrvderfZ/ar6spZv1t1c+ib6LHbsA11YwcNo+H3ft AS76u66mOy1rgqgP30+/VIO2BQPTixQunOwthP3ysyrah6psuAuk7I1Ft SXJjrZFv+8lskhWbLZhNgxlp7ut/5QyWCLBKUgZcmdpAc3WyLueutYKMb 1yQHNS8ERgeS7MZjl9kTeIijHrDfNjhzr8NyTf+xIewe5cOGu7d5pHVaD Fh3jtX39mxknFWo0mFWODBR8+kU8PqkeZs/sYFsrMtdR8VDqY7wxM6kHL d5DVLWJbjBI/aHkzVPGxbvCRipE83x3ILPnaR1AhrbGrbdYY8MDySia1o A==; X-IronPort-AV: E=Sophos;i="5.93,241,1654531200"; d="scan'208";a="320941884" Received: from h199-255-45-15.hgst.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 16 Aug 2022 23:42:45 +0800 IronPort-SDR: FmChNdgVFwkBfVZpc9z5/fMDmEDlae2mrXlF0kzUR8WtLTUVoC3mvadHTeNrAH8Q3JlDtpQDuk auMHNrhVdIcO+VwQkVaNPSgOyCj0V8Jn59Nli519WldruzU/c3NZtFmXyxTyjQM0tiU92opkc5 0xogY2+oJ6rb7l9Kixziv77nQ+2X1Rpktn1nPtZI0gEYfix8ZXzt2nZfTJ180OXRnNA4cIL6MH qJvC1stJ/rM01AtTOKh6NCfnwhGDuFOQkUZHd4n9tJ+PWRcmZqITRG4wxl1eDZfkwwYTX3KSGP 5jCOQZR64sWF2IBQtigosIC3 Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 16 Aug 2022 07:58:13 -0700 IronPort-SDR: iEeU3xPKfXpOmuERAaNuAnrfLivwSSXP6+uOp4+rp3Y1N6O6XL4Hcqx7dSD/zxuNZ5u+UHcwM9 BeRve9lgzUaqjS0KzYfmC18avRJMbx34xdOXIVbzDmOUwKfrfLo5DLwiav+ylLFvKvLtKUQtDK kBwcXRUOQO+RDfurGv4ZoC9B8ujVkmFcwBTk+B+x9rIH01TxqxiKbev2fVKxzuGkapJNb8OTPH f51lIWKGpTPKf8CENardrB68gy/yJghJwCrH0GIqf71L6Nwvs69VXtxdkZXa7pEYMOiis8lDxE BdE= WDCIronportException: Internal Received: from usg-ed-osssrv.wdc.com ([10.3.10.180]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 16 Aug 2022 08:42:46 -0700 Received: from usg-ed-osssrv.wdc.com (usg-ed-osssrv.wdc.com [127.0.0.1]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTP id 4M6b505LJjz1Rwqy for ; Tue, 16 Aug 2022 08:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= opensource.wdc.com; h=content-transfer-encoding:content-type :in-reply-to:organization:from:references:to:content-language :subject:user-agent:mime-version:date:message-id; s=dkim; t= 1660664563; x=1663256564; bh=4pLJV4ar6F2DZGfMkGTvI6mAYr0kU7DMXxS q+tx3CnI=; b=e0qjTEK1a/CGS/wzw8PO1PPgqa5Mh4ewGrb9xtlNIw/XtP6zjNb t4gQD91p3DRj1OF7hSAPR8ENxjL3nGvWhVqHV3j5cULreJvOxbSPo7+b7S4EEFuV 9uMJ1mR1wUnNU0WJdMLvxzVY8hLkJB6bEWCBelCx5JPJSCyfmtiM69KUc1LisJjY 6ZCvFZXvEBZyOOeKOgKqGNX9uCy096KNfrLGCZuhLGiSBc+TfBr6rxH/cy7BBrRe kr8+bH/VKtIjiXK8F2M6W6zo/c6QLxPJwSXWjZUo+YtJZBzfChhxcUPjjLtgoIHD bkCrXBWIu2AGeRtNv0lvxxmTDi440sArQZA== X-Virus-Scanned: amavisd-new at usg-ed-osssrv.wdc.com Received: from usg-ed-osssrv.wdc.com ([127.0.0.1]) by usg-ed-osssrv.wdc.com (usg-ed-osssrv.wdc.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sD6srpd-qBmo for ; Tue, 16 Aug 2022 08:42:43 -0700 (PDT) Received: from [10.111.64.29] (c02drav6md6t.sdcorp.global.sandisk.com [10.111.64.29]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTPSA id 4M6b4z2HJkz1RtVk; Tue, 16 Aug 2022 08:42:43 -0700 (PDT) Message-ID: <43eaa104-5b09-072c-56aa-6289569b0015@opensource.wdc.com> Date: Tue, 16 Aug 2022 08:42:42 -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: John Garry , Oliver Sang Cc: Christoph Hellwig , "Martin K. Petersen" , LKML , Linux Memory Management List , linux-ide@vger.kernel.org, lkp@lists.01.org, lkp@intel.com, ying.huang@intel.com, feng.tang@intel.com, zhengjun.xing@linux.intel.com, fengwei.yin@intel.com References: <1f498d4a-f93f-ceb4-b713-753196e5e08d@opensource.wdc.com> <3451fa5a-6229-073f-ae18-0c232cd48ed5@huawei.com> <2e9cf5a6-c043-5ccf-e363-097c6c941891@huawei.com> From: Damien Le Moal Organization: Western Digital Research In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660664567; a=rsa-sha256; cv=none; b=CC90aiAltzn4dr8AMzKtjjeCyz7fGAnDbqHL0xXc1zbMb8wUg190/RL+HvphXeQYJupeUd nw/YVYlTa/ayG2D2IMr+/pMfEEB22b8607bFtcUEkGpx+3NIOgBiaKu4LJGGOBZsZMOASb G9+JcePRJPHKqT+Pe+AZTRq6exWJytM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none ("invalid DKIM record") header.d=wdc.com header.s=dkim.wdc.com header.b=hmcVktkk; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b=e0qjTEK1; spf=pass (imf02.hostedemail.com: domain of "prvs=22053a6f0=damien.lemoal@opensource.wdc.com" designates 68.232.141.245 as permitted sender) smtp.mailfrom="prvs=22053a6f0=damien.lemoal@opensource.wdc.com"; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660664567; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=17g9IuUfUO9h8oPM3P7zjAM6KEqs/9EsBb58bvpWAg8=; b=a2X3/7RuH1HfOW26q1uGa9Ajz1azogIJQNbzWL5DwJ4vP7mjLKOpP61P4qQBWOMSWL22Rl /DMKVcxn66JI8weIBdT9/6s29ShelZJ8Y326wHJetRY/vCfaO/58wSXM6mVDarK5IDONZd /SNh6TP3rSm7ZMmHUsqi4lQhAtrPQfE= X-Stat-Signature: rzxebrwqeuem35m5jjfogmg3cgs8bwf3 X-Rspamd-Queue-Id: 1113680035 Authentication-Results: imf02.hostedemail.com; dkim=none ("invalid DKIM record") header.d=wdc.com header.s=dkim.wdc.com header.b=hmcVktkk; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b=e0qjTEK1; spf=pass (imf02.hostedemail.com: domain of "prvs=22053a6f0=damien.lemoal@opensource.wdc.com" designates 68.232.141.245 as permitted sender) smtp.mailfrom="prvs=22053a6f0=damien.lemoal@opensource.wdc.com"; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com X-Rspam-User: X-Rspamd-Server: rspam03 X-HE-Tag: 1660664566-272176 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022/08/16 3:35, John Garry wrote: > On 16/08/2022 07:57, Oliver Sang wrote: >>>> For me, a complete kernel log may help. >>> and since only 1HDD, the output of the following would be helpful: >>> >>> /sys/block/sda/queue/max_sectors_kb >>> /sys/block/sda/queue/max_hw_sectors_kb >>> >>> And for 5.19, if possible. >> for commit >> 0568e61225 ("ata: libata-scsi: cap ata_device->max_sectors according to shost->max_sectors") >> >> root@lkp-icl-2sp1 ~# cat /sys/block/sda/queue/max_sectors_kb >> 512 >> root@lkp-icl-2sp1 ~# cat /sys/block/sda/queue/max_hw_sectors_kb >> 512 >> >> for both commit >> 4cbfca5f77 ("scsi: scsi_transport_sas: cap shost opt_sectors according to DMA optimal limit") >> and v5.19 >> >> root@lkp-icl-2sp1 ~# cat /sys/block/sda/queue/max_sectors_kb >> 1280 >> root@lkp-icl-2sp1 ~# cat /sys/block/sda/queue/max_hw_sectors_kb >> 32767 >> > > thanks, I appreciate this. > > From the dmesg, I see 2x SATA disks - I was under the impression that > the system only has 1x. > > Anyway, both drives show LBA48, which means the large max hw sectors at > 32767KB: > [ 31.129629][ T1146] ata6.00: 1562824368 sectors, multi 1: LBA48 NCQ > (depth 32) > > So this is what I suspected: we are capped from the default shost max > sectors (1024 sectors). > > This seems like the simplest fix for you: > > --- a/include/linux/libata.h > +++ b/include/linux/libata.h > @@ -1382,7 +1382,8 @@ extern const struct attribute_group > *ata_common_sdev_groups[]; > .proc_name = drv_name, \ > .slave_destroy = ata_scsi_slave_destroy, \ > .bios_param = ata_std_bios_param, \ > - .unlock_native_capacity = ata_scsi_unlock_native_capacity > + .unlock_native_capacity = ata_scsi_unlock_native_capacity,\ > + .max_sectors = ATA_MAX_SECTORS_LBA48 This is crazy large (65535 x 512 B sectors) and never result in that being exposed as the actual max_sectors_kb since other limits will apply first (mapping size). The regression may come not from commands becoming tiny, but from the fact that after the patch, max_sectors_kb is too large, causing a lot of overhead with qemu swiotlb mapping and slowing down IO processing. Above, it can be seen that we ed up with max_sectors_kb being 1280, which is the default for most scsi disks (including ATA drives). That is normal. But before that, it was 512, which likely better fits qemu swiotlb and does not generate overhead. So the above fix will not change anything I think... > A concern is that other drivers which use libata may have similar > issues, as they use default in SCSI_DEFAULT_MAX_SECTORS for max_sectors: > hisi_sas > pm8001 > aic9xxx > mvsas > isci > > So they may be needlessly hobbled for some SATA disks. However I have a > system with hisi_sas controller and attached LBA48 disk. I tested > performance for v5.19 vs 6.0 and it was about the same for fio rw=read @ > ~120K IOPS. I can test this further. > > Thanks, > John -- Damien Le Moal Western Digital Research