On Fri, Aug 27, 2021 at 05:00:11PM +0100, Joao Martins wrote: > So felt like doing it inline straight away inline when calling percpu_ref_get_many(): > > (pfn_end(pgmap, range_id) - pfn_first(pgmap, range_id)) / pgmap_geometry(pgmap); > > I can switch to a shift if you prefer: > > (pfn_end(pgmap, range_id) - pfn_first(pgmap, range_id)) > << pgmap_geometry_order(pgmap); Yes. A shift is less overhead than a branch. > > Also geometry sounds a bit strange, even if I can't really > > offer anything better offhand. > > > We started with @align (like in device dax core), and then we switched > to @geometry because these are slightly different things (one relates > to vmemmap metadata structure (number of pages) and the other is how > the mmap is aligned to a page size. I couldn't suggest anything else, > besides a more verbose name like vmemmap_align maybe. It for sure isn't an alignment. I think the term that comes closest is a granularity. But something like vmemmap_shift if switching to a shift might be descriptive enough for the struct member name.
