On Wed, Jul 10, 2019 at 10:26:47PM +0200, Jan Kara wrote: > On Wed 10-07-19 13:15:39, Matthew Wilcox wrote: > > On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote: > > > +#define DAX_ENTRY_CONFLICT dax_make_entry(pfn_to_pfn_t(1), DAX_EMPTY) > > > > I was hoping to get rid of DAX_EMPTY ... it's almost unused now. Once > > we switch to having a single DAX_LOCK value instead of a single bit, > > I think it can go away, freeing up two bits. > > > > If you really want a special DAX_ENTRY_CONFLICT, I think we can make > > one in the 2..4094 range. > > > > That aside, this looks pretty similar to the previous patch I sent, so > > if you're now happy with this, let's add > > > > #define XA_DAX_CONFLICT_ENTRY xa_mk_internal(258) > > > > to xarray.h and do it that way? > > Yeah, that would work for me as well. The chosen value for DAX_ENTRY_CONFLICT > was pretty arbitrary. Or we could possibly use: > > #define DAX_ENTRY_CONFLICT XA_ZERO_ENTRY > > so that we don't leak DAX-specific internal definition into xarray.h? I don't want to use the ZERO entry as our conflict marker because that could legitimately appear in an XArray. Not the i_pages XArray today, but I hold out hope for using that in place of the DAX_ZERO_PAGE bit too. That's going to be a bit more tricky since we currently distinguish between DAX_ZERO_PAGE and DAX_ZERO_PAGE | DAX_PMD. However, the XA_RETRY_ENTRY might be a good choice. It doesn't normally appear in an XArray (it may appear if you're looking at a deleted node, but since we're holding the lock, we can't see deleted nodes).
