On 9/1/21 10:44 AM, Christoph Hellwig wrote: > 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. > OK. But FWIW, the overhead of this shift or branch doesn't matter much compared to the rest of memremap_pages(). >>> 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. > Hmmm, it would be a 'shift related to vmemmap' in the literal sense but while descriptive of the field it doesn't tell much otherwise. geometry is probably used more widely for block device term when Dan suggested the term. Alternatively, vmemmap_compound_nr / vmemmap_npages (if it represents a nr of pages per compound page) or vmemmap_order (which is more clear on what it is than vmemmap_shift?). Changing to a 'order'/'shift' representation also gets the 'being a power of 2' enforcement for free. And compound pages IIUC always represent a power-of-2 number of pages. Joao
