Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Krishna Reddy <vdumpa@nvidia.com>
To:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
CC:     Robin Murphy <robin.murphy@arm.com>,
        "linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        Will Deacon <will@kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        Thierry Reding <treding@nvidia.com>
Subject: RE: [PATCH] iommu/io-pgtable-arm: Optimize partial walk flush for
 large scatter-gather list
Thread-Topic: [PATCH] iommu/io-pgtable-arm: Optimize partial walk flush for
 large scatter-gather list
Thread-Index: AQHXXT84btg0466hEE2rkvq94oyuZasMBHAAgACy+QCAAD6WAIAAB6mAgAAg2ACAAAWcgIAAPESAgACQdxCAAA05AIABAqfQ
Date:   Fri, 11 Jun 2021 16:49:54 +0000
Message-ID: <BY5PR12MB376480219C42E5FCE0FE0FFBB3349@BY5PR12MB3764.namprd12.prod.outlook.com>
References: <20210609145315.25750-1-saiprakash.ranjan@codeaurora.org>
 <dbcd394a-4d85-316c-5dd0-033546a66132@arm.com>
 <c600e9b2534d54082a5272b508a7985f@codeaurora.org>
 <35bfd245-45e2-8083-b620-330d6dbd7bd7@arm.com>
 <12067ffb8243b220cf03e83aaac3e823@codeaurora.org>
 <266f190e-99ae-9175-cf13-7a77730af389@arm.com>
 <dfdabcdec99a4c6e3bf2b3c5eebe067f@codeaurora.org>
 <61c69d23-324a-85d7-2458-dfff8df9280b@arm.com>
 <BY5PR12MB37646698F37C00381EFF7C77B3349@BY5PR12MB3764.namprd12.prod.outlook.com>
 <07001b4ed6c0a491eacce6e4dc13ab5e@codeaurora.org>
In-Reply-To: <07001b4ed6c0a491eacce6e4dc13ab5e@codeaurora.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?J8QMuYNSWp6zXWuQyMMTOPxL49BkmIkJX6TvzN1XUJJRLMOXbi6YWkfWRopu?=
 =?us-ascii?Q?+YbvX7DDu4sG1BhsWXJJOH2tt/i29/fOvi9D+XmwDz7jF5IHqDe6/HItEivh?=
 =?us-ascii?Q?VmRQq7G7tMRaIYChmiJSLJUHnOQxg5t3orlIAuqw0Vq3MEHBRnln2jmjA9sM?=
 =?us-ascii?Q?jmyvrwKfy0S1dHXZbAeD7s6fYnGtLq8G9+kawxHnUPifA5rnrj565NtprFIW?=
 =?us-ascii?Q?KXk7CM5gARmiPDdqQcjjKX7wgjMBYLzJXmQiE8blRczlDSAlME8iyKR+N0El?=
 =?us-ascii?Q?dKpMgReBzAG+C978Bwv+7JdC3cLUFeWA97FdqBGVkCm5PSJCXn0tC4WPuzh+?=
 =?us-ascii?Q?cX6ZdixpK1iXWPwKHw8Fais22LmXc42XK006R0N1ibRax+MJCJ9hUgLdHL4U?=
 =?us-ascii?Q?/SpCDKbYogvtoEEbFeWxewZ/PpnA/Hw2bmon9F/or4mrD9KADs4RCIZEtPs7?=
 =?us-ascii?Q?IBs3u2s75ZwWG2TGB0f2w2VOGx7juNqta5nTYn33tNDuZlFAKP44/LhUbBru?=
 =?us-ascii?Q?wRE4VH9hV3kgPkucPElteDgxJ/srPwdAPWRkibXRy9OXU4y0xWGrCP2Fgf/G?=
 =?us-ascii?Q?gEK1esBou7dYukJoN4G82zcew/7FmMaCWVJJYRJgs0CqIRNt1P72W9AlGj2f?=
 =?us-ascii?Q?i9O1EsdPlSCFhWXOzhuzgIr9/fkHdiH8D4POQFVWeAyznWsBQEyc5AXCzZT4?=
 =?us-ascii?Q?w/rxQk1e9q4QTzaQLTQcUr1yGWLwTDtVxqDyvfGNc0uYRWFoQ/9s+hadXBn/?=
 =?us-ascii?Q?Vrg9bNyTNegNRAYSN/QZYDBHZ32iBbQTKuasHebGEAi0mA0eeAcwlKEgWXpx?=
 =?us-ascii?Q?wW8YLcrhxDRRQnp/1ky4MKRUng6e+Jxjq0TqqfIwp87L6bubGbIvjZto6QCk?=
 =?us-ascii?Q?KTW6+CikRVrqoS0sLjgLFYEwgaIGGqE6zGg9Jiu/j+6uK5N5tM7JH1vTBaAp?=
 =?us-ascii?Q?QCEAQScZFxtKV2jqweA3Guop0HdyWgS7b/ofNHQidOuiAPofPs5e6Gmrhd25?=
 =?us-ascii?Q?+aWxU/eU98+KJ2hV+gqu8r8uQ8iTHxfKrzUmHKe9nS3/pOX5+4RSN9MsMiAo?=
 =?us-ascii?Q?BXZCAAYBChhVxsuXA+xSroXka/AypVwo3pB8jhH2RwyBnqhGt7IK6bE8TPaw?=
 =?us-ascii?Q?uTP8i9o1it1XFPpeVkLAwh+OthMXt0B47WIlqRa/HbwfKF6uLhOp25lb0yVy?=
 =?us-ascii?Q?79Lnp/OfxxnKkwFlpm1MMRxpdPQBmIBdRPaXJ3y5NId+gP5NYchDF1nzFmei?=
 =?us-ascii?Q?F3c0xyeBX2nNCBEuqJWWL97TeG8z/jkMBmVKuAjo5YBiZKP+h/EJK/KLNoHR?=
 =?us-ascii?Q?ZvIvt+aOi5E4XyeVl9A7mtdw?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB3764.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e148353-9cbe-4fa9-1b21-08d92cf8f0da
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2021 16:49:55.2144
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OKRDVM9JdY620BWzdf2TshCKxIJT7Jy2rlcOfar5qJXfRWIqeYk6XiTTc3bfOCerWPx2yoBw9RVqmiMiJDxQtw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB4744
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Sai,
> >> > No, the unmap latency is not just in some test case written, the
> >> > issue is very real and we have workloads where camera is reporting
> >> > frame drops because of this unmap latency in the order of 100s of
> milliseconds.

> Not exactly, this issue is not specific to camera. If you look at the num=
bers in the
> commit text, even for the test device its the same observation. It depend=
s on
> the buffer size we are unmapping which affects the number of TLBIs issue.=
 I am
> not aware of any such HW side bw issues for camera specifically on QCOM
> devices.

It is clear that reducing number of TLBIs  reduces the umap API latency. Bu=
t, It is
at the expense of throwing away valid tlb entries.=20
Quantifying the impact of arbitrary invalidation of valid tlb entries at co=
ntext level is not straight forward and
use case dependent. The side-effects might be rare or won't be known until =
they are noticed.
Can you provide more details on How the unmap latency is causing camera to =
drop frames?
Is unmap performed in the perf path?
If unmap is queued and performed on a back ground thread, would it resolve =
the frame drops?

-KR