On Mon, May 05, 2025 at 02:31:01PM -0300, Jason Gunthorpe wrote: > On Mon, May 05, 2025 at 10:27:30AM -0700, Nicolin Chen wrote: > > > So when calling mtree_alloc_range: > > > > > > int mtree_alloc_range(struct maple_tree *mt, unsigned long *startp, > > > void *entry, unsigned long size, unsigned long min, > > > unsigned long max, gfp_t gfp) > > > > > > size should be the number of PFNs this mmap is going to use, which is > > > not sizeof() anything > > > > > > min should be 0 and max should be uh.. U32_MAX >> PAGE_SHIFT > > > IIRC.. There is a different limit for pgof fon 32 bit mmap() > > > > Should the startp (input) be the pfn_start (i.e. pgoff)? > > pfn_start/pgoff is the output of the allocation, it is not an input.
Sorry, I got it wrong. Not "startp": it's an output that should be returned to user space, as pgoff of mmap. I wanted to ask: what should we pass in to the "entry"? An mmap structure that hold the pfn range? Or just pfn_start? > > In this case, it would return startp as the ID, which will > > be further returned to the user space. So, basically user > > space know the pfn range, v.s being given an mmap cookie? > > Userspace is given the pgoff to pass to mmap as a cookie, it doesn't > know anything about it beyond that passing that pgoff will get the > mmap it should get. Userspace must also know how big the mmap is. Yes. I got this part. > The pgoffs should all be allocated from non-overlapping ranges as > though they were bytes in a file so that the mmaps are all > disjoint. This makes debugging easier and the API saner. > > There is no "id" here.. Ah, right. "ID" is more of the xarray term. Here it's "startp" right? And it would be used as the "index" for mtree_load(). With that being said, it seems that I have been misusing the mtree data structure, treating it as an xarray. In your very first email suggesting the mmap design, where you mentioned "xarray" first and "maple tree" following. So, I thought they can be used in the similar way, especially after reading this: https://lwn.net/Articles/846175/ Thanks Nicolin
