On Tue, 2025-08-19 at 19:55 +1000, Alistair Popple wrote: > 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.
One thing that the linked list avoids, though, is traversing the interval tree two times. It has O(n*log(n)) whereas the linked list overhead is just O(n_2pass). > > 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. One idea is for any two-pass notifier implementation to use a small pool. That would also to some extent mitigate the risk of out-of-memory with GFP_NOWAIT. /Thomas > > > Jason > >
