On Mon, Aug 29, 2016 at 9:08 PM, Matthew Wilcox <[email protected]> wrote: > The DAX lock bit is analogous to the PageLock. You can't serialise on the > mapping lock; the contention will be too high.
I mean DAX lock bit is protected by mapping lock thus we can set/clear it for all entries if needed. > > And the point of having the radix tree support the same entry for many > indices is that we don't have to go and probe the radix tree multiple times > looking for the first or last entry. We just look up the index, then use the > entry we got back. Right, but lookup function can also return pointer for node -- fininding first or last entries is trivial here. We could simply scan back/forward or if huge DAX order is known then just align slot pointer to first or last entry. > > -----Original Message----- > From: Konstantin Khlebnikov [mailto:[email protected]] > Sent: Monday, August 29, 2016 12:14 PM > To: Matthew Wilcox <[email protected]> > Cc: Ross Zwisler <[email protected]>; [email protected] > Subject: Re: [PATCH RFC 1/4] lib/radix: add universal radix_tree_fill_range > > On Mon, Aug 29, 2016 at 6:21 PM, Matthew Wilcox <[email protected]> > wrote: >> Thanks, Ross. >> >> Konstantin, I think there are problems with the concept behind this series. >> You have multiple entries in the tree with the same value. That works out >> fine when the entry is a pointer (eg to a struct page), but not so well when >> it's an exceptional entry (eg a swap cache entry or a DAX radix tree entry). >> If you look at the recent DAX work, you'll see there's a lock bit, and >> having multiple lock bits is a recipe for disaster. >> > > I see no problem here. They could use lock bit at first or last entry. > Anyway all changes should be protecred by lock at mapping. > >
