public inbox for linux-ide@vger.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Bart Van Assche <bvanassche@acm.org>,
	<damien.lemoal@opensource.wdc.com>, <joro@8bytes.org>,
	<will@kernel.org>, <jejb@linux.ibm.com>,
	<martin.petersen@oracle.com>, <hch@lst.de>,
	<m.szyprowski@samsung.com>, <robin.murphy@arm.com>
Cc: <linux-scsi@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<liyihang6@hisilicon.com>, <linux-kernel@vger.kernel.org>,
	<linux-ide@vger.kernel.org>, <iommu@lists.linux-foundation.org>
Subject: Re: [PATCH v3 3/4] scsi: core: Cap shost max_sectors according to DMA optimum mapping limits
Date: Thu, 23 Jun 2022 09:36:12 +0100	[thread overview]
Message-ID: <c973c0d1-49a4-e0d5-2d2e-4eefeb91099f@huawei.com> (raw)
In-Reply-To: <f7872ebc-dfe5-d977-c51f-91b73e6d1fbb@huawei.com>

On 10/06/2022 16:37, John Garry via iommu wrote:
> 
>> On 6/9/22 10:54, John Garry wrote:
>>> ok, but do you have a system where the UFS host controller is behind 
>>> an IOMMU? I had the impression that UFS controllers would be mostly 
>>> found in embedded systems and IOMMUs are not as common on there.
>>
>> Modern phones have an IOMMU. Below one can find an example from a 
>> Pixel 6 phone. The UFS storage controller is not controller by the 
>> IOMMU as far as I can see but I wouldn't be surprised if the security 
>> team would ask us one day to enable the IOMMU for the UFS controller.
> 
> OK, then unfortunately it seems that you have no method to test. I might 
> be able to test USB MSC but I am not even sure if I can even get DMA 
> mappings who length exceeds the IOVA rcache limit there.

I was able to do some testing on USB MSC for an XHCI controller. The 
result is that limiting the max HW sectors there does not affect 
performance in normal conditions.

However if I hack the USB driver and fiddle with request queue settings 
then it can:
- lift max_sectors limit in usb_stor_host_template 120KB -> 256KB
- lift request queue read_ahead_kb 128KB -> 256KB

In this scenario I can get 42.5MB/s read throughput, as opposed to 
39.5MB/s in normal conditions. Since .can_queue=1 for that host it would 
not fall foul of some issues I experience in IOVA allocator performance, 
so limiting max_sectors would not be required for that reason.

So this is an artificial test, but it may be worth considering only 
applying this DMA mapping optimal max_sectors limit to SAS controllers 
which I know can benefit.

Christoph, any opinion?

thanks,
John

  reply	other threads:[~2022-06-23  8:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06  9:30 [PATCH v3 0/4] DMA mapping changes for SCSI core John Garry
2022-06-06  9:30 ` [PATCH v3 1/4] dma-mapping: Add dma_opt_mapping_size() John Garry
2022-06-08 17:27   ` Bart Van Assche
2022-06-06  9:30 ` [PATCH v3 2/4] dma-iommu: Add iommu_dma_opt_mapping_size() John Garry
2022-06-08 17:26   ` Bart Van Assche
2022-06-08 17:39     ` John Garry
2022-06-14 13:12   ` John Garry
2022-06-23  8:38     ` John Garry
2022-06-06  9:30 ` [PATCH v3 3/4] scsi: core: Cap shost max_sectors according to DMA optimum mapping limits John Garry
2022-06-08 17:33   ` Bart Van Assche
2022-06-08 17:50     ` John Garry
2022-06-08 21:07       ` Bart Van Assche
2022-06-09  8:00         ` John Garry
2022-06-09 17:18           ` Bart Van Assche
2022-06-09 17:54             ` John Garry
2022-06-09 20:34               ` Bart Van Assche
2022-06-10 15:37                 ` John Garry
2022-06-23  8:36                   ` John Garry [this message]
2022-06-06  9:30 ` [PATCH v3 4/4] libata-scsi: Cap ata_device->max_sectors according to shost->max_sectors John Garry
2022-06-07 22:43 ` [PATCH v3 0/4] DMA mapping changes for SCSI core Bart Van Assche
2022-06-08 10:14   ` John Garry

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=c973c0d1-49a4-e0d5-2d2e-4eefeb91099f@huawei.com \
    --to=john.garry@huawei.com \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jejb@linux.ibm.com \
    --cc=joro@8bytes.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=liyihang6@hisilicon.com \
    --cc=m.szyprowski@samsung.com \
    --cc=martin.petersen@oracle.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox