From: Baolu Lu <baolu.lu@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
Joerg Roedel <joro@8bytes.org>
Cc: baolu.lu@linux.intel.com, David Woodhouse <dwmw2@infradead.org>,
"Raj, Ashok" <ashok.raj@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"Kumar, Sanjay K" <sanjay.k.kumar@intel.com>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH] iommu/vt-d: Avoid superfluous IOTLB tracking in lazy mode
Date: Tue, 7 Feb 2023 14:45:37 +0800 [thread overview]
Message-ID: <b190ddb3-eb1d-cd72-ce03-1127af228bf0@linux.intel.com> (raw)
In-Reply-To: <BN9PR11MB52764498929E4978B3A8740D8CDA9@BN9PR11MB5276.namprd11.prod.outlook.com>
On 2023/2/6 11:48, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> Sent: Saturday, February 4, 2023 2:32 PM
>>
>> On 2023/2/4 7:04, Jacob Pan wrote:
>>> Intel IOMMU driver implements IOTLB flush queue with domain selective
>>> or PASID selective invalidations. In this case there's no need to track
>>> IOVA page range and sync IOTLBs, which may cause significant
>> performance
>>> hit.
>>
>> [Add cc Robin]
>>
>> If I understand this patch correctly, this might be caused by below
>> helper:
>>
>> /**
>> * iommu_iotlb_gather_add_page - Gather for page-based TLB invalidation
>> * @domain: IOMMU domain to be invalidated
>> * @gather: TLB gather data
>> * @iova: start of page to invalidate
>> * @size: size of page to invalidate
>> *
>> * Helper for IOMMU drivers to build invalidation commands based on
>> individual
>> * pages, or with page size/table level hints which cannot be gathered
>> if they
>> * differ.
>> */
>> static inline void iommu_iotlb_gather_add_page(struct iommu_domain
>> *domain,
>> struct
>> iommu_iotlb_gather *gather,
>> unsigned long iova,
>> size_t size)
>> {
>> /*
>> * If the new page is disjoint from the current range or is
>> mapped at
>> * a different granularity, then sync the TLB so that the gather
>> * structure can be rewritten.
>> */
>> if ((gather->pgsize && gather->pgsize != size) ||
>> iommu_iotlb_gather_is_disjoint(gather, iova, size))
>> iommu_iotlb_sync(domain, gather);
>>
>> gather->pgsize = size;
>> iommu_iotlb_gather_add_range(gather, iova, size);
>> }
>>
>> As the comments for iommu_iotlb_gather_is_disjoint() says,
>>
>> "...For many IOMMUs, flushing the IOMMU in this case is better
>> than merging the two, which might lead to unnecessary invalidations.
>> ..."
>>
>> So, perhaps the right fix for this performance issue is to add
>>
>> if (!gather->queued)
>>
>> in iommu_iotlb_gather_add_page() or iommu_iotlb_gather_is_disjoint()?
>> It should benefit other arch's as well.
>>
>
> There are only two callers of this helper: intel and arm-smmu-v3.
>
> Looks other drivers just implements direct flush via io_pgtable_tlb_add_page().
>
> and their unmap callback typically does:
>
> if (!iommu_iotlb_gather_queued(gather))
> io_pgtable_tlb_add_page();
>
> from this angle it's same policy as Jacob's does, i.e. if it's already
> queued then no need to further call optimization for direct flush.
Perhaps we can use iommu_iotlb_gather_queued() to replace direct
gather->queued check in this patch as well?
Best regards,
baolu
next prev parent reply other threads:[~2023-02-07 6:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 23:04 [PATCH] iommu/vt-d: Avoid superfluous IOTLB tracking in lazy mode Jacob Pan
2023-02-04 6:32 ` Baolu Lu
2023-02-06 3:48 ` Tian, Kevin
2023-02-07 6:45 ` Baolu Lu [this message]
2023-02-07 9:18 ` Tian, Kevin
2023-02-06 11:20 ` Robin Murphy
2023-02-07 6:42 ` Baolu Lu
2023-02-06 11:05 ` Robin Murphy
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=b190ddb3-eb1d-cd72-ce03-1127af228bf0@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jacob.jun.pan@linux.intel.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=sanjay.k.kumar@intel.com \
--cc=stable@vger.kernel.org \
--cc=yi.l.liu@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: link
Be 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.