On 14-Mar-19 15:43, Jason Gunthorpe wrote: > On Thu, Mar 14, 2019 at 03:23:49PM +0200, Gal Pressman wrote: > >> I'm not certain that 32 bits are enough in this case. >> The eight most significant bits are reserved for internal coding, which leaves >> us with 24 bits for the key. > > '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. > >> 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? > > .. and with any scheme won't you run out of BAR pages well before you > hit an limit here.. Ie 24 bits of 4K pages is 68G of mappable space! > > .. and if you are worried about such large lists then that linear > search is not going to cut it either. 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.
