On Thu, Nov 23, 2023 at 07:11:19PM +0000, Ryan Roberts wrote:
> Hi,
> I'm not sure I've 100% understood the crossover between this series and my 
> work
> to support arm64's contpte mappings generally for anonymous and file-backed 
> memory.

No worry, there's no confliction.  If you worked on that it's only be
something nice on top.  Also, I'm curious if you have performance numbers,
because I'm going to do some test for hugetlb cont_ptes (which is only the
current plan), and if you got those it'll be a great baseline for me,
because it should be similar in you case even though the goal is slightly

> My approach is to transparently use contpte mappings when core-mm request pte
> mappings that meet the requirements; and its all based around intercepting the
> normal (non-hugetlb) helpers (e.g. set_ptes(), ptep_get() and friends). There 
> is
> no semantic change to the core-mm. See [1]. It relies on 1) the page cache 
> using
> large folios and 2) my "small-sized THP" series which starts using arbitrary
> sized large folios for anonymous memory [2].
> If I've understood this conversation correctly there is an object called 
> hugepd,
> which today is only supported by powerpc, but which could allow the core-mm to
> control the mapping granularity? I can see some value in exposing that control
> to core-mm in the (very) long term.

For me it's needed immediately, because hugetlb_follow_page_mask() will be
gone after the last patch.

> [1] https://lore.kernel.org/all/20231115163018.1303287-1-ryan.robe...@arm.com/
> [2] 
> https://lore.kernel.org/linux-mm/20231115132734.931023-1-ryan.robe...@arm.com/

AFAICT you haven't yet worked on gup then, after I glimpsed the above

It's a matter of whether one follow_page_mask() call can fetch more than
one page* for a cont_pte entry on aarch64 for a large non-hugetlb folio
(and if this series lands, it'll be the same to hugetlb or non-hugetlb).
Now the current code can only fetch one page I think.


Peter Xu

Reply via email to