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 741C7C25B08 for ; Wed, 17 Aug 2022 15:55:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB40E6B0073; Wed, 17 Aug 2022 11:55:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3CBA6B0074; Wed, 17 Aug 2022 11:55:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8E988D0001; Wed, 17 Aug 2022 11:55:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A2A1C6B0073 for ; Wed, 17 Aug 2022 11:55:09 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7547C160A7B for ; Wed, 17 Aug 2022 15:55:09 +0000 (UTC) X-FDA: 79809533538.07.9744A8C Received: from esa6.hgst.iphmx.com (esa6.hgst.iphmx.com [216.71.154.45]) by imf15.hostedemail.com (Postfix) with ESMTP id 71D74A01E1 for ; Wed, 17 Aug 2022 15:55:08 +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=1660751708; x=1692287708; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Da4nMJ1F9CkVDkvWNzoxhW66X+iNWqedHoEO8QVLg1M=; b=Xs2nLwWrtkgcmtJzGCWCKLNn9yQsiuUVVeaDpPDUYD7bJv7zkF+XKgo7 uDZhwo6M7viGVvOAlHGjlESeMNQcmAwKIZdXLDtF15Q58fU5g77yMz8wE NyjlcH+ybdLUOBEIujtEyHy1ALbg8SDY/DHjGmXE8w+IYkUlY+fwzU6wH 3QLuSWsrDz+0z9ccMLYRRlhWRbPvwa+HrALZ3jY9z2RyXlF3hjbk0m8JN dylBL/ybnbUiJkTRTLmN3147NWNzDcCvcOerScg7IpbOhPJho5PW9aYoL wDy9jHGr2KO/kqo3sRpNum0mAI/k+aWWVibIM5hY10cTl0hTWm4BSgd0e g==; X-IronPort-AV: E=Sophos;i="5.93,243,1654531200"; d="scan'208";a="209481377" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 17 Aug 2022 23:55:03 +0800 IronPort-SDR: BUsJOFl2IwgnY2dJp866cfZGdGNd4iHHiTh4Diw+VzJKtl2RAPTPzzcICQyT/N6gk+/gipSF95 YdwbLp5yjNa1HvWkRlHs0mDmwYEF+bXVP12c6BpISGNXlHkmCa96D0NaABNOFgARdx6qw7IJr5 EnjrFbPabhD8IWmc3vTgE1fzxMlUKT3+IY+kLEo8Wa689Xlr++PKmRlFIXeQHKmwUhg5FwQCle TQ0FOoljM+lzTJn5ZnrW/VpO2eBlbq4MdPUwNLHuWjFZJbdFqQj2+elOHQ+bNqbHNkVbNSemVd hTifITzD6b2RbmR1qR8F9nrW 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; 17 Aug 2022 08:10:30 -0700 IronPort-SDR: H3k+lD780vKrGVBztIfp6ZRiqSOZRmBcTQHTed7LBDw3xnluVqjkDJzztGFNHkGOTWVUxbD1oV kmiTsEjoCW8CxHqAdTAnDrtyrpE0NdocJ+TJIPGVmCVt02rsB/TFVn3O0oFeiDdHGo7B8z4xQS UjEuFVHTdiBw9nEYkTfXrPJyEbO4b0+5j9wrYodss4XXymWiPzQbFRZEZoit6DGFhocsRhjsuB 0XQfOwCoRVYbsIxBARxYcUbQLviH2N8Yjocz1JLiDxxgzde48/QnN04UJCYiOvCGo04+CaZzFn 8Po= 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; 17 Aug 2022 08:55:04 -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 4M7CJk58DGz1Rw4L for ; Wed, 17 Aug 2022 08:55:02 -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= 1660751701; x=1663343702; bh=Da4nMJ1F9CkVDkvWNzoxhW66X+iNWqedHoE O8QVLg1M=; b=a8E4b6TYglEZqemoz/IvureRzXS2h0BxBVr6myCFT2djYIy2Q8a uOrg4utMi2iF33DWYAUjZqOmQaw1UBg+6PgpvdnUc0iK3eCJPYfDxFwhTf6dfmTY JHnFaA/ID4knX74B60BkhAOSskHkaZkiSU6f38w2oHAMtukmu3yxxD/Xs5Lru4Zp sxx4mUhPpPhdUoL3KQ6NLjyBu2lS0QUZIsOdWFD7Pl5qXlud0P12cRKB95aXshh1 QMDX19qWOf/gEkJY/DXJihU7aS22PvfgMk07HAt18C2uG2m0ArHlQOxCAS74EytQ p1z4ZW1/Gu7LXGJqpKytFjoPi5uNgNzKd6g== 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 CyYqqsmqF5zq for ; Wed, 17 Aug 2022 08:55:01 -0700 (PDT) Received: from [10.11.46.122] (unknown [10.11.46.122]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTPSA id 4M7CJh5Fs8z1RtVk; Wed, 17 Aug 2022 08:55:00 -0700 (PDT) Message-ID: Date: Wed, 17 Aug 2022 08:55:00 -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> <43eaa104-5b09-072c-56aa-6289569b0015@opensource.wdc.com> <28d6e48b-f52f-9467-8260-262504a1a1ff@huawei.com> <05a48c68-33ae-10e2-e565-6c124bad93c5@opensource.wdc.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=1660751709; a=rsa-sha256; cv=none; b=KZJb2LbCVmDYhBymUcu9t0lVrPz0JTlySW+D1IKqbQibuZqSBTqLrkWFN4P4NqtTjf2G7O oNbSR27FpzcduB3Q7gCOENi7BUotgOqSQQjpaUTZfMsdPvEbIZ+H4VUpP74NrRR6gR/dad IG2UV3FW7meF1J3xenvbV47VRGK/06A= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none ("invalid DKIM record") header.d=wdc.com header.s=dkim.wdc.com header.b=Xs2nLwWr; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b=a8E4b6TY; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com; spf=pass (imf15.hostedemail.com: domain of "prvs=221a806df=damien.lemoal@opensource.wdc.com" designates 216.71.154.45 as permitted sender) smtp.mailfrom="prvs=221a806df=damien.lemoal@opensource.wdc.com" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660751709; 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=GzMwGMLSteFOaFDEv7JG26KD6/IgfESgn2KoGr12Ei0=; b=wUQqHOaz6NVz671aCBuYG+Ttb/Prrr9TyL2N70iuqmconFFxzd5xBWGtXJW/eAnF+6mINN Ok/RSIw9/8Th+TcBMTz8Y076mb9+JlqnP13ytHu3e65BKi+6PWhx26k7+TyZxnZutdw5V6 NoJW1t76bN8K4RCvP+e2ybfTcTKCkKw= X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 71D74A01E1 X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=none ("invalid DKIM record") header.d=wdc.com header.s=dkim.wdc.com header.b=Xs2nLwWr; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b=a8E4b6TY; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com; spf=pass (imf15.hostedemail.com: domain of "prvs=221a806df=damien.lemoal@opensource.wdc.com" designates 216.71.154.45 as permitted sender) smtp.mailfrom="prvs=221a806df=damien.lemoal@opensource.wdc.com" X-Stat-Signature: stzrwmixootwga5ofu7crta77pwfh1xu X-HE-Tag: 1660751708-647932 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 13:44, John Garry wrote: > On 16/08/2022 21:02, Damien Le Moal wrote: >>> ou confirm this? Thanks! >>> >>> On this basis, it appears that max_hw_sectors_kb is getting capped from >>> scsi default @ 1024 sectors by commit 0568e61225. If it were getting >>> capped by swiotlb mapping limit then that would give us 512 sectors - >>> this value is fixed. >>> >>> So for my SHT change proposal I am just trying to revert to previous >>> behaviour in 5.19 - make max_hw_sectors_kb crazy big again. >> I reread the entire thing and I think I got things reverted here. The perf >> regression happens with the 512/512 settings, while the original 1280/32767 >> before your patches was OK. > > Right, that's as I read it. It would be useful for Oliver to confirm the > results. > >> So is your patch defining the optimal mapping size >> cause the reduction to 512/512. > > The optimal mapping size only affects specifically sas controllers, so I > think that we can ignore that one for now. The reduction to 512/512 > comes from the change in ata_scsi_dev_config(). > >> It would mean that for ATA, we need a sane >> default mapping instead of SCSI default 1024 sectors. > > Right > >> Now I understand your >> proposed change using ATA_MAX_SECTORS_LBA48. >> >> However, that would be correct only for LBA48 capable drives. >> ata_dev_configure() already sets dev->max_sectors correctly according to the >> drive type, capabilities and eventual quirks. So the problem comes from the >> libata-scsi change: >> >> dev->max_sectors = min(dev->max_sectors, sdev->host->max_sectors); >> >> when sdev->host->max_sectors is 0 (not initialized). > > That cannot happen. If sht->max_sectors is 0, then we set > shost->max_sectors at SCSI default 1024 sectors in scsi_host_alloc() > > For my proposed change, dev->max_sectors would still be initialized in > ata_dev_configure() according to drive type, etc. And it should be <= > LBA48 max sectors (=65535). > > So then in ata_scsi_dev_config(): > > dev->max_sectors = min(dev->max_sectors, sdev->host->max_sectors) > > this only has an impact for ahci controllers if sdev->host->max_sectors > was capped according to host dma dev max mapping size. Got it. I think your fix is fine then. It brings everything the defaults to what they were before the dma max mapping patches. > > I will admit that this is not ideal. An alt approach is to change > ata_scsi_dev_config() to cap the dev max_sectors only according to shost > dma dev mapping limit (similar to scsi_add_host_with_dma()), but that > would not work for a controller like ipr, which does have a geniune > max_sectors limit (which we should respect). > > Thanks, > John > > >> So maybe simply changing >> this line to: >> >> dev->max_sectors = min_not_zero(dev->max_sectors, sdev->host->max_sectors); >> >> would do the trick ? Any particular adapter driver that needs a mapping cap on >> the adpter max mapping size can still set sdev->host->max_sectors as needed, and >> we keep the same defaults as before when it is not set. Thoughts ? Or am I >> missing something else ? >> >> >>>> The regression may come not from commands becoming tiny, but from the fact that >>>> after the patch, max_sectors_kb is too large, >>> I don't think it is, but need confirmation. >>> >>>> 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 >>> Again, I don't think this this is the case. Need confirmation. >>> >>>> overhead. So the above fix will not change anything I think... > -- Damien Le Moal Western Digital Research