The DAX lock bit is analogous to the PageLock. You can't serialise on the mapping lock; the contention will be too high.
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. -----Original Message----- From: Konstantin Khlebnikov [mailto:koc...@gmail.com] Sent: Monday, August 29, 2016 12:14 PM To: Matthew Wilcox <mawil...@microsoft.com> Cc: Ross Zwisler <ross.zwis...@linux.intel.com>; linux-kernel@vger.kernel.org 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 <mawil...@microsoft.com> 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.
