On 2021-12-14 14:48, Will Deacon wrote:
On Tue, Dec 07, 2021 at 02:32:48PM +0800, Zhou Wang wrote:
The commit f115f3c0d5d8 ("iommu/arm-smmu-v3: Decrease the queue size of
evtq and priq") decreases evtq and priq, which may lead evtq/priq to be
full with fault events, e.g HiSilicon ZIP/SEC/HPRE have maximum 1024 queues
in one device, every queue could be binded with one process and trigger a
fault event. So let's revert f115f3c0d5d8.
In fact, if an implementation of SMMU really does not need so long evtq
and priq, value of IDR1_EVTQS and IDR1_PRIQS can be set to proper ones.
Signed-off-by: Zhou Wang <wangzh...@hisilicon.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
I'd like an Ack from Zhen Lei on this, as the aim of the original patch
was to reduce memory consumption.
I wonder if it's time to start trying to be a bit cleverer than just
allocating the smallest/largest possible queues, and try to scale them
to some heuristic of the "size" of the system? Certainly a module
parameter so that users can manually tune for their system/workload
might be a reasonable compromise.
I'm also tempted by the idea of trying to dynamically reallocate larger
queues if they fill up, but I guess that depends on whether it's already
game over if events or PRI requests are lost...
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
