linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zi Yan <ziy@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Lance Yang <ioworker0@gmail.com>,
	Alistair Popple <apopple@nvidia.com>,
	akpm@linux-foundation.org, willy@infradead.org, sj@kernel.org,
	maskray@google.com, ryan.roberts@arm.com, david@redhat.com,
	21cnbao@gmail.com, mhocko@suse.com, fengwei.yin@intel.com,
	zokeefe@google.com, shy828301@gmail.com, xiehuan09@gmail.com,
	libang.li@antgroup.com, wangkefeng.wang@huawei.com,
	songmuchun@bytedance.com, peterx@redhat.com, minchan@kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Baolin Wang <baolin.wang@linux.alibaba.com>
Subject: Re: [PATCH v4 2/3] mm/rmap: integrate PMD-mapped folio splitting into pagewalk loop
Date: Wed, 08 May 2024 12:22:08 -0400	[thread overview]
Message-ID: <30469615-2DDC-467E-A810-5EE8E1CFCB43@nvidia.com> (raw)
In-Reply-To: <20240508155253.GK4650@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

On 8 May 2024, at 11:52, Jason Gunthorpe wrote:

> On Wed, May 08, 2024 at 10:56:34AM -0400, Zi Yan wrote:
>
>> Lance is improving try_to_unmap_one() to support unmapping PMD THP as a whole,
>> so he moves split_huge_pmd_address() inside while (page_vma_mapped_walk(&pvmw))
>> and after mmu_notifier_invalidate_range_start() as split_huge_pmd_locked()
>> and does not include the mmu notifier ops inside split_huge_pmd_address().
>> I wonder if that could cause issues, since the mmu_notifier_invalidate_range_start()
>> before the while loop only has range of the original address and
>> split huge pmd can affect the entire PMD address range and these two ranges
>> might not be the same.
>
> That does not sound entirely good..
>
> I suppose it depends on what split does, if the MM page table has the
> same translation before and after split then perhaps no invalidation
> is even necessary.

Before split, it is a PMD mapping to a PMD THP (order-9). After split,
they are 512 PTEs mapping to the same THP. Unless the secondary TLB
does not support PMD mapping and use 512 PTEs instead, it seems to
be an issue from my understanding.

In terms of two mmu_notifier ranges, first is in the split_huge_pmd_address()[1]
and second is in try_to_unmap_one()[2]. When try_to_unmap_one() is unmapping
a subpage in the middle of a PMD THP, the former notifies about the PMD range
change due to one PMD split into 512 PTEs and the latter only needs to notify
about the invalidation of the unmapped PTE. I do not think the latter can
replace the former, although a potential optimization can be that the latter
can be removed as it is included in the range of the former.

Regarding Lance's current code change, is it OK to change mmu_notifier range
after mmu_notifier_invalidate_range_start()? Since in Lance's code, first
mmu_notifier is gone and second, whose range is only about the single PTE,
starts mmu_notifier_invalidate_range_start(), then the code finds that
a PMD needs to be split into 512 PTEs. Would changing the range from PTE
to PMD suffice? Or the code should call mmu_notifier_invalidate_range_start()
with the new PMD range? I am not even sure two start with one end is legit.

[1] https://elixir.bootlin.com/linux/v6.9-rc7/source/mm/huge_memory.c#L2658
[2] https://elixir.bootlin.com/linux/v6.9-rc7/source/mm/rmap.c#L1650

--
Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

  reply	other threads:[~2024-05-08 16:22 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-01  4:26 [PATCH v4 0/3] Reclaim lazyfree THP without splitting Lance Yang
2024-05-01  4:26 ` [PATCH v4 1/3] mm/rmap: remove duplicated exit code in pagewalk loop Lance Yang
2024-05-07 14:51   ` Zi Yan
2024-05-07 14:53     ` Lance Yang
2024-05-01  4:26 ` [PATCH v4 2/3] mm/rmap: integrate PMD-mapped folio splitting into " Lance Yang
2024-05-07  3:40   ` Baolin Wang
2024-05-07  4:37     ` Lance Yang
2024-05-07  8:17       ` David Hildenbrand
2024-05-07  8:38         ` Lance Yang
2024-05-07 17:22           ` Andrew Morton
2024-05-07 17:33             ` David Hildenbrand
2024-05-07 17:38               ` Andrew Morton
2024-05-07 18:30                 ` David Hildenbrand
2024-05-07 15:26   ` Zi Yan
2024-05-08  5:43     ` Lance Yang
2024-05-08 14:07       ` Zi Yan
2024-05-08 14:35         ` Lance Yang
2024-05-08 14:48           ` Zi Yan
2024-05-08 14:56             ` Zi Yan
2024-05-08 15:52               ` Jason Gunthorpe
2024-05-08 16:22                 ` Zi Yan [this message]
2024-05-08 16:35                   ` Jason Gunthorpe
2024-05-09  8:21                     ` Lance Yang
2024-05-09 14:53                       ` Zi Yan
2024-05-09  8:56                     ` Lance Yang
2024-05-01  4:27 ` [PATCH v4 3/3] mm/vmscan: avoid split lazyfree THP during shrink_folio_list() Lance Yang
2024-05-07  4:00   ` Baolin Wang
2024-05-07  6:32     ` Lance Yang
2024-05-07  8:26       ` Lance Yang
2024-05-07  9:33         ` Baolin Wang
2024-05-07 11:37           ` Lance Yang
2024-05-09  9:36             ` Baolin Wang
2024-05-09 12:17               ` Lance Yang
2024-05-07 16:20   ` Zi Yan
2024-05-08  5:14     ` Lance Yang
2024-05-01 16:08 ` [PATCH v4 0/3] Reclaim lazyfree THP without splitting SeongJae Park
2024-05-02  0:30   ` Lance Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30469615-2DDC-467E-A810-5EE8E1CFCB43@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=fengwei.yin@intel.com \
    --cc=ioworker0@gmail.com \
    --cc=jgg@nvidia.com \
    --cc=libang.li@antgroup.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maskray@google.com \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=peterx@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=sj@kernel.org \
    --cc=songmuchun@bytedance.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=xiehuan09@gmail.com \
    --cc=zokeefe@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox