Thread (12 messages) 12 messages, 3 authors, 8d ago

Re: [PATCH RFC v2 1/4] iommu/arm-smmu-v3: Convert streams from RB tree to XArray

From: Nicolin Chen <hidden>
Date: 2026-09-22 16:57:51
Also in: linux-iommu, lkml

On Tue, Sep 22, 2026 at 10:04:39PM +0800, Peng Fan wrote:
quoted
... and slightly mentions "simplifies". Maybe it should write about
why this is necessary and how xarray would simplify vs RB tree?
Jean had a comment that "maybe simplify the driver first by moving to a xarray",
see [1] [2].

[1] https://lore.kernel.org/linux-iommu/20230518130459.GA2587493@myrica/ (local)
[2] https://lore.kernel.org/linux-iommu/ecb3725c-27c4-944b-b42c-f4e293521f94@arm.com/#t (local)
You should have put a suggested-by tag and likely one of the links
as well.

With that being said, I don't see the reasoning in those emails very
convincing either. I don't dislike xarray. Yet in this series, there
seems no compelling reason on switching RB tree to xarray.
A subsequent patch needs to look up an existing stream by SID and
then decide to share it rather than reject it - two separate
operations. The RB tree's rb_find_add() fuses lookup and insertion
atomically: it either inserts or returns the collision, making
"find, then conditionally share" impossible without restructuring.
XArray's xa_load() and xa_store() are independent operations that
naturally support this pattern.
If you avoid duplicated stream structures as I suggested in PATCH-2,
there is no need of that, since you would only insert once to the RB
tree.

Nicolin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help