From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 776CDC4320A for ; Wed, 1 Sep 2021 09:44:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BAA8861026 for ; Wed, 1 Sep 2021 09:44:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BAA8861026 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 22C466B006C; Wed, 1 Sep 2021 05:44:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B5148D0001; Wed, 1 Sep 2021 05:44:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07DD36B0072; Wed, 1 Sep 2021 05:44:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id E85826B006C for ; Wed, 1 Sep 2021 05:44:51 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8D114181C98E8 for ; Wed, 1 Sep 2021 09:44:51 +0000 (UTC) X-FDA: 78538520382.05.3C5BA90 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf03.hostedemail.com (Postfix) with ESMTP id ECA1930000A5 for ; Wed, 1 Sep 2021 09:44:50 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 3F54868AFE; Wed, 1 Sep 2021 11:44:47 +0200 (CEST) Date: Wed, 1 Sep 2021 11:44:46 +0200 From: Christoph Hellwig To: Joao Martins Cc: Christoph Hellwig , linux-mm@kvack.org, Dan Williams , Vishal Verma , Dave Jiang , Naoya Horiguchi , Matthew Wilcox , Jason Gunthorpe , John Hubbard , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org Subject: Re: [PATCH v4 04/14] mm/memremap: add ZONE_DEVICE support for compound pages Message-ID: <20210901094446.GA29632@lst.de> References: <20210827145819.16471-1-joao.m.martins@oracle.com> <20210827145819.16471-5-joao.m.martins@oracle.com> <20210827153308.GA20687@lst.de> <9ee23c67-e600-555a-85fc-d527b1484bcc@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ee23c67-e600-555a-85fc-d527b1484bcc@oracle.com> User-Agent: Mutt/1.5.17 (2007-11-01) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=none (imf03.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: ECA1930000A5 X-Stat-Signature: ocbj5o4krpouzhcmoud8ioxndzj8tmgf X-HE-Tag: 1630489490-929290 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.