On Mon, Aug 18, 2025 at 01:46:55PM -0300, Jason Gunthorpe wrote: > On Mon, Aug 18, 2025 at 09:44:01AM -0700, Matthew Brost wrote: > > On Mon, Aug 18, 2025 at 01:36:17PM -0300, Jason Gunthorpe wrote: > > > On Mon, Aug 18, 2025 at 09:25:20AM -0700, Matthew Brost wrote: > > > > I think this choice makes sense: it allows embedding the wait state from > > > > the initial notifier call into the pass structure. Patch [6] shows this > > > > by attaching the issued TLB invalidation fences to the pass. Since a > > > > single notifier may be invoked multiple times with different ranges but > > > > the same seqno, > > > > > > That should be explained, but also seems to be a bit of a different > > > issue.. > > > > > > If the design is really to only have two passes and this linked list > > > is about retaining state then there should not be so much freedom to > > > have more passes. > > > > I’ll let Thomas weigh in on whether we really need more than two passes; > > my feeling is that two passes are likely sufficient. It’s also worth > > noting that the linked list has an added benefit: the notifier tree only > > needs to be walked once (a small time-complexity win). > > You may end up keeping the linked list just with no way to add a third > pass.
It seems to me though that linked list still adds unnecessary complexity. I think this would all be much easier to follow if we just added two new callbacks - invalidate_start() and invalidate_end() say. Admitedly that would still require the linked list (or something similar) to retain the ability to hold/pass a context between the start and end callbacks. Which is bit annoying, it's a pity we need to allocate memory in a performance sensitive path to effectively pass (at least in this case) a single pointer. I can't think of any obvious solutions to that though. > Jason >
