On Thu, Mar 14, 2019 at 05:38:34PM +0200, Gal Pressman wrote: > > 'internal coding' ? Why aren't those in the upper (32+PAGE_SIZE) bits? > > We can do that. > The user will still "see" a 64 bit key where anything above 32 bits will not > increment. This is fine > >> The key is increasing in strides of PAGE_SIZE (4k or possibly more). > > > > No you always shift the key >> PAGE_SHIFT. > > I don't follow. > The key is incremented by PAGE_SIZE since the vma holds the offset in pages > granularity. Advancing it with anything less than PAGE_SIZE will result in the > same vm_pgoff right? Every file offset 'key/cookie' has zero in the lower PAGE_SHIFT bits, as mmap only works on page aligned offsets. The xarray key should be the page number to access - converted from the offset by stripping the lower PAGE_SHIFT bits (done by vm_pgoff already) and masking the upper flag bits. So with the 64 bit offset argument you only have 52 bits to to work with. - 12 are zero for PAGE_SHIFT - 32 are the page number for the xarray key - N are padding - N are the flags at a fixed location in the 64 bit offset Userspace rdma-core can always use a 64 bit file offset for mmap. > I'll take a look into changing this into an xarray. > What did you mean by a cyclic allocating xarray? We can't reuse the keys as the > entries should be valid until application exit. Use xa_alloc_cyclic Jason
