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 CAD30C25B0E for ; Tue, 16 Aug 2022 20:44:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59D036B0073; Tue, 16 Aug 2022 16:44:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54A9C6B0074; Tue, 16 Aug 2022 16:44:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EC7F8D0001; Tue, 16 Aug 2022 16:44:39 -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 313026B0073 for ; Tue, 16 Aug 2022 16:44:39 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0653D1A1044 for ; Tue, 16 Aug 2022 20:44:39 +0000 (UTC) X-FDA: 79806634278.19.A953554 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf04.hostedemail.com (Postfix) with ESMTP id 5C505401A4 for ; Tue, 16 Aug 2022 20:44:37 +0000 (UTC) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M6jgf5VMJz67N4d; Wed, 17 Aug 2022 04:39:42 +0800 (CST) Received: from lhrpeml500003.china.huawei.com (7.191.162.67) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 16 Aug 2022 22:44:34 +0200 Received: from [10.195.244.204] (10.195.244.204) by lhrpeml500003.china.huawei.com (7.191.162.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 16 Aug 2022 21:44:33 +0100 Message-ID: Date: Tue, 16 Aug 2022 21:44:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [ata] 0568e61225: stress-ng.copy-file.ops_per_sec -15.0% regression To: Damien Le Moal , Oliver Sang CC: Christoph Hellwig , "Martin K. Petersen" , LKML , "Linux Memory Management List" , , , , , , , 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: John Garry In-Reply-To: <05a48c68-33ae-10e2-e565-6c124bad93c5@opensource.wdc.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.195.244.204] X-ClientProxiedBy: lhrpeml100003.china.huawei.com (7.191.160.210) To lhrpeml500003.china.huawei.com (7.191.162.67) X-CFilter-Loop: Reflected ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660682677; 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; bh=Vrc6124aALFU0NfTBaaR+oYVUjowfqgFRHgiQbwKGbQ=; b=Wbtks84JI55nkFqFML4UbWRif4QYMD3TgtAwzoEN1tX45ScYriAA/SIUr4Q61cbL6lK4Jk kIr9do7Sv6okAii4VbqGysso/ygBVy+fltJz6++LZWJbPRAZLKrnnuUhSpXkpi3J+iY/hb YtjyEQNO2JwBkkap7Ob6iGSDY3SS7Tg= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of john.garry@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=john.garry@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660682677; a=rsa-sha256; cv=none; b=ndFsZCGzPHX/wPzy+L4Ua4lSNBn7XplXalO4mQ67eVtRF5vXKduREb28n5QLzVdC0UW3VR 6CsO/QQ42KoR2sfB0KrLxCIHdvxLuWho/BIqxBLLswhK46Xp+w9L48DIe5zKz2Og4hR6Al W6L4VVOiKNJPFmWSAu4gojSrwf4+9Xw= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5C505401A4 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of john.garry@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=john.garry@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Stat-Signature: 5bwi3hxa6jccmsf3aryawqnkndkim5b7 X-HE-Tag: 1660682677-540558 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 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. 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...