From: Damien Le Moal <damien.lemoal@opensource.wdc.com> To: 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, lkp@lists.01.org, lkp@intel.com, ying.huang@intel.com, feng.tang@intel.com, zhengjun.xing@linux.intel.com, fengwei.yin@intel.com Subject: Re: [ata] 0568e61225: stress-ng.copy-file.ops_per_sec -15.0% regression Date: Wed, 10 Aug 2022 06:52:03 -0700 [thread overview] Message-ID: <b3ce0a28-0f94-6d2a-3f88-998da8f870b4@opensource.wdc.com> (raw) In-Reply-To: <82dbf4d6-2d43-20ff-22a7-857f9f11a5ce@huawei.com> On 2022/08/10 1:33, John Garry wrote: > On 09/08/2022 15:57, Damien Le Moal wrote: >>>> 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. >>> For __ATA_BASE_SHT, we don't set max_sectors. As such, we default >>> shost->max_sectors = SCSI_DEFAULT_MAX_SECTORS (=1024) in >>> scsi_host_alloc(). I assume no shost dma mapping limit applied. >>> >>> Then - for example - we could select dev->max_sectors = >>> ATA_MAX_SECTORS_LBA48 (=65535) in ata_dev_configure(). >>> >>> So with commit 0568e6122574 we would have final max sectors = 1024, as >>> opposed to 65535 previously. I guess that the problem is something like >>> this. >>> >>> If so, it seems that we would need to apply the shost dma mapping limit >>> separately in ata_scsi_dev_config() and not use shost->max_sectors. >> OK. Will have a look at that. >> > > We may need to introduce something like shost->max_hw_sectors, which is > set according to sht max sectors and dma mapping limits. That could be > also used in USB scsiglue slave_configure() > > Or else set max_sectors value for __ATA_BASE_SHT, but I don't know a > sane value there considering ATA_MAX_SECTORS_LBA48 gives max_sectors of > 65535. > > Damien, please let me know if you need help now. I am just waiting for > you to test to prove this theory about dev->max_sectors being capped. I > don't have an AHCI setup readily-available for testing - just SAS cards > or QEMU. I am on it. > > Thanks, > John -- Damien Le Moal Western Digital Research
WARNING: multiple messages have this Message-ID (diff)
From: Damien Le Moal <damien.lemoal@opensource.wdc.com> To: lkp@lists.01.org Subject: Re: [ata] 0568e61225: stress-ng.copy-file.ops_per_sec -15.0% regression Date: Wed, 10 Aug 2022 06:52:03 -0700 [thread overview] Message-ID: <b3ce0a28-0f94-6d2a-3f88-998da8f870b4@opensource.wdc.com> (raw) In-Reply-To: <82dbf4d6-2d43-20ff-22a7-857f9f11a5ce@huawei.com> [-- Attachment #1: Type: text/plain, Size: 1625 bytes --] On 2022/08/10 1:33, John Garry wrote: > On 09/08/2022 15:57, Damien Le Moal wrote: >>>> 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. >>> For __ATA_BASE_SHT, we don't set max_sectors. As such, we default >>> shost->max_sectors = SCSI_DEFAULT_MAX_SECTORS (=1024) in >>> scsi_host_alloc(). I assume no shost dma mapping limit applied. >>> >>> Then - for example - we could select dev->max_sectors = >>> ATA_MAX_SECTORS_LBA48 (=65535) in ata_dev_configure(). >>> >>> So with commit 0568e6122574 we would have final max sectors = 1024, as >>> opposed to 65535 previously. I guess that the problem is something like >>> this. >>> >>> If so, it seems that we would need to apply the shost dma mapping limit >>> separately in ata_scsi_dev_config() and not use shost->max_sectors. >> OK. Will have a look at that. >> > > We may need to introduce something like shost->max_hw_sectors, which is > set according to sht max sectors and dma mapping limits. That could be > also used in USB scsiglue slave_configure() > > Or else set max_sectors value for __ATA_BASE_SHT, but I don't know a > sane value there considering ATA_MAX_SECTORS_LBA48 gives max_sectors of > 65535. > > Damien, please let me know if you need help now. I am just waiting for > you to test to prove this theory about dev->max_sectors being capped. I > don't have an AHCI setup readily-available for testing - just SAS cards > or QEMU. I am on it. > > Thanks, > John -- Damien Le Moal Western Digital Research
next prev parent reply other threads:[~2022-08-10 13:52 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-05 8:05 [ata] 0568e61225: stress-ng.copy-file.ops_per_sec -15.0% regression kernel test robot 2022-08-05 8:05 ` kernel test robot 2022-08-08 14:52 ` Damien Le Moal 2022-08-08 14:52 ` Damien Le Moal 2022-08-09 9:58 ` John Garry 2022-08-09 9:58 ` John Garry 2022-08-09 14:16 ` John Garry 2022-08-09 14:16 ` John Garry 2022-08-09 14:57 ` Damien Le Moal 2022-08-09 14:57 ` Damien Le Moal 2022-08-10 8:33 ` John Garry 2022-08-10 8:33 ` John Garry 2022-08-10 13:52 ` Damien Le Moal [this message] 2022-08-10 13:52 ` Damien Le Moal 2022-08-09 14:55 ` Damien Le Moal 2022-08-09 14:55 ` Damien Le Moal 2022-08-09 15:16 ` David Laight 2022-08-09 15:16 ` David Laight 2022-08-10 13:57 ` Damien Le Moal 2022-08-10 13:57 ` Damien Le Moal 2022-08-12 5:01 ` Oliver Sang 2022-08-12 5:01 ` Oliver Sang 2022-08-12 11:13 ` John Garry 2022-08-12 11:13 ` John Garry 2022-08-12 14:58 ` John Garry 2022-08-12 14:58 ` John Garry 2022-08-16 6:57 ` Oliver Sang 2022-08-16 6:57 ` Oliver Sang 2022-08-16 10:35 ` John Garry 2022-08-16 10:35 ` John Garry 2022-08-16 15:42 ` Damien Le Moal 2022-08-16 15:42 ` Damien Le Moal 2022-08-16 16:38 ` John Garry 2022-08-16 16:38 ` John Garry 2022-08-16 20:02 ` Damien Le Moal 2022-08-16 20:02 ` Damien Le Moal 2022-08-16 20:44 ` John Garry 2022-08-16 20:44 ` John Garry 2022-08-17 15:55 ` Damien Le Moal 2022-08-17 15:55 ` Damien Le Moal 2022-08-17 13:51 ` Oliver Sang 2022-08-17 13:51 ` Oliver Sang 2022-08-17 14:04 ` John Garry 2022-08-17 14:04 ` John Garry 2022-08-18 2:06 ` Oliver Sang 2022-08-18 2:06 ` Oliver Sang 2022-08-18 9:28 ` John Garry 2022-08-18 9:28 ` John Garry 2022-08-19 6:24 ` Oliver Sang 2022-08-19 6:24 ` Oliver Sang 2022-08-19 7:54 ` John Garry 2022-08-19 7:54 ` John Garry 2022-08-20 16:36 ` Damien Le Moal 2022-08-20 16:36 ` Damien Le Moal 2022-08-12 15:41 ` Damien Le Moal 2022-08-12 15:41 ` Damien Le Moal 2022-08-12 17:17 ` John Garry 2022-08-12 17:17 ` John Garry 2022-08-12 18:27 ` Damien Le Moal 2022-08-12 18:27 ` Damien Le Moal 2022-08-13 7:23 ` John Garry 2022-08-13 7:23 ` John Garry 2022-08-16 2:52 ` Oliver Sang 2022-08-16 2:52 ` Oliver Sang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=b3ce0a28-0f94-6d2a-3f88-998da8f870b4@opensource.wdc.com \ --to=damien.lemoal@opensource.wdc.com \ --cc=feng.tang@intel.com \ --cc=fengwei.yin@intel.com \ --cc=hch@lst.de \ --cc=john.garry@huawei.com \ --cc=linux-ide@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lkp@intel.com \ --cc=lkp@lists.01.org \ --cc=martin.petersen@oracle.com \ --cc=oliver.sang@intel.com \ --cc=ying.huang@intel.com \ --cc=zhengjun.xing@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.