lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZN5oojF6vKOKB/eI@Asurada-Nvidia>
Date:   Thu, 17 Aug 2023 11:36:18 -0700
From:   Nicolin Chen <nicolinc@...dia.com>
To:     <will@...nel.org>, <robin.murphy@....com>, <jgg@...dia.com>
CC:     <joro@...tes.org>, <jean-philippe@...aro.org>,
        <apopple@...dia.com>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <iommu@...ts.linux.dev>
Subject: Re: [PATCH v2] iommu/arm-smmu-v3: Add a user-configurable
 tlb_invalidate_threshold

On Wed, Aug 16, 2023 at 01:43:50PM -0700, Nicolin Chen wrote:
 
> When receiving an __arm_smmu_tlb_inv_range() call with a large size, there
> could be a long latency at this function call: one part is coming from a
> large software overhead in the routine of building commands, and the other
> part is coming from CMDQ hardware consuming the large number of commands.
> This latency could be significantly large on an SMMU that does not support
> range invalidation commands, i.e. no ARM_SMMU_FEAT_RANGE_INV.
> 
> One way to optimize this is to replace a large number of VA invalidation
> commands with one single per-asid invalidation command, when the requested
> size reaches a threshold. This threshold can be configurable depending on
> the SMMU implementaion.

I'm rethinking about this size-based threshold, since what really
affects the latency is the number of the invalidation commands in
the request. So having an npages-based threshold might be optimal,
though the idea and implementation would be similar.

Thanks
Nicolin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ