Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 11 Jan 2023 16:51:36 -0500
From:   Peter Xu <peterx@redhat.com>
To:     James Houghton <jthoughton@google.com>
Cc:     Mike Kravetz <mike.kravetz@oracle.com>,
        Muchun Song <songmuchun@bytedance.com>,
        David Hildenbrand <david@redhat.com>,
        David Rientjes <rientjes@google.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Mina Almasry <almasrymina@google.com>,
        Zach O'Keefe <zokeefe@google.com>,
        Manish Mishra <manish.mishra@nutanix.com>,
        Naoya Horiguchi <naoya.horiguchi@nec.com>,
        "Dr . David Alan Gilbert" <dgilbert@redhat.com>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        Baolin Wang <baolin.wang@linux.alibaba.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        Yang Shi <shy828301@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 13/46] hugetlb: add hugetlb_hgm_walk and hugetlb_walk_step
Message-ID: <Y78vaNW10X6vUKjA@x1n>
References: <20230105101844.1893104-1-jthoughton@google.com>
 <20230105101844.1893104-14-jthoughton@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230105101844.1893104-14-jthoughton@google.com>
Precedence: bulk

On Thu, Jan 05, 2023 at 10:18:11AM +0000, James Houghton wrote:

[...]

> +static int hugetlb_hgm_walk_uninit(struct hugetlb_pte *hpte,

Nitpick on the name: the "uninit" can be misread into pairing with some
other "init()" calls..

How about just call it hugetlb_hgm_walk (since it's the higher level API
comparing to the existing one)?  Then the existing hugetlb_hgm_walk can be
called hugetlb_hgm_do_walk/__hugetlb_hgm_walk since it's one level down.

> +				   pte_t *ptep,
> +				   struct vm_area_struct *vma,
> +				   unsigned long addr,
> +				   unsigned long target_sz,
> +				   bool alloc)
> +{
> +	struct hstate *h = hstate_vma(vma);
> +
> +	hugetlb_pte_populate(vma->vm_mm, hpte, ptep, huge_page_shift(h),
> +			     hpage_size_to_level(huge_page_size(h)));

Another nitpick on name: I remembered we used to reach a consensus of using
hugetlb_pte_init before?  Can we still avoid the word "populate" (if "init"
is not suitable since it can be updated during stepping, how about "setup")?

[...]

> +int hugetlb_walk_step(struct mm_struct *mm, struct hugetlb_pte *hpte,
> +		      unsigned long addr, unsigned long sz)
> +{
> +	pte_t *ptep;
> +	spinlock_t *ptl;
> +
> +	switch (hpte->level) {
> +	case HUGETLB_LEVEL_PUD:
> +		ptep = (pte_t *)hugetlb_alloc_pmd(mm, hpte, addr);
> +		if (IS_ERR(ptep))
> +			return PTR_ERR(ptep);
> +		hugetlb_pte_populate(mm, hpte, ptep, PMD_SHIFT,
> +				     HUGETLB_LEVEL_PMD);
> +		break;
> +	case HUGETLB_LEVEL_PMD:
> +		ptep = hugetlb_alloc_pte(mm, hpte, addr);
> +		if (IS_ERR(ptep))
> +			return PTR_ERR(ptep);
> +		ptl = pte_lockptr(mm, (pmd_t *)hpte->ptep);
> +		__hugetlb_pte_populate(hpte, ptep, PAGE_SHIFT,
> +				       HUGETLB_LEVEL_PTE, ptl);
> +		hpte->ptl = ptl;

This line seems to be superfluous (even if benign).

> +		break;
> +	default:
> +		WARN_ONCE(1, "%s: got invalid level: %d (shift: %d)\n",
> +				__func__, hpte->level, hpte->shift);
> +		return -EINVAL;
> +	}
> +	return 0;
> +}
> +
>  /*
>   * Return a mask that can be used to update an address to the last huge
>   * page in a page table page mapping size.  Used to skip non-present
> -- 
> 2.39.0.314.g84b9a713c41-goog
> 

-- 
Peter Xu