All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zi Yan <ziy@nvidia.com>
To: Peter Xu <peterx@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	Nathan Chancellor <nathan@kernel.org>,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
	kaleshsingh@google.com, npiggin@gmail.com,
	joel@joelfernandes.org,
	Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: Re: [PATCH v5 3/9] mm/mremap: Use pmd/pud_poplulate to update page table entries
Date: Thu, 20 May 2021 15:06:30 -0400	[thread overview]
Message-ID: <4CE7132C-3800-456B-91DA-613391361B94@nvidia.com> (raw)
In-Reply-To: <YKZ49Nrz2OojQUBR@t490s>

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

On 20 May 2021, at 10:57, Peter Xu wrote:

> On Thu, May 20, 2021 at 07:07:57PM +0530, Aneesh Kumar K.V wrote:
>> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>>
>>> On 5/20/21 6:16 PM, Peter Xu wrote:
>>>> On Thu, May 20, 2021 at 01:56:54PM +0530, Aneesh Kumar K.V wrote:
>>>>>> This seems to work at least for my userfaultfd test on shmem, however I don't
>>>>>> fully understand the commit message [1] on: How do we guarantee we're not
>>>>>> moving a thp pte?
>>>>>>
>>>>>
>>>>> move_page_tables() checks for pmd_trans_huge() and ends up calling
>>>>> move_huge_pmd if it is a THP entry.
>>>>
>>>> Sorry to be unclear: what if a huge pud thp?
>>>>
>>>
>>> I am still checking. Looking at the code before commit
>>> c49dd340180260c6239e453263a9a244da9a7c85, I don't see kernel handling
>>> huge pud thp. I haven't studied huge pud thp enough to understand
>>> whether c49dd340180260c6239e453263a9a244da9a7c85 intent to add that
>>> support.
>>>
>>> We can do a move_huge_pud() like we do for huge pmd thp. But I am not
>>> sure whether we handle those VMA's earlier and restrict mremap on them?
>>
>> something like this? (not even compile tested). I am still not sure
>> whether this is really needed or we handle DAX VMA's in some other form.
>
> Yeah maybe (you may want to at least drop that extra "case HPAGE_PUD").
>
> It's just that if with CONFIG_HAVE_MOVE_PUD (x86 and arm64 enables it by
> default so far) it does seem to work even with huge pud, while after this patch
> it seems to be not working anymore, even with your follow up fix.
>
> Indeed I saw CONFIG_HAVE_MOVE_PUD is introduced a few months ago so breaking
> someone seems to be unlikely, perhaps no real user yet to mremap() a huge pud
> for dax or whatever backend?
>
> Ideally maybe rework this patch (or series?) and repost it for a better review?
> Agree the risk seems low.  I'll leave that to you and Andrew to decide..

It seems that the mremap function for 1GB DAX THP was not added when 1GB DAX THP
was implemented[1]. I guess no one is using mremap on 1GB DAX THP. Maybe we want
to at least add a warning or VM_BUG_ON to catch this or use Aneesh’s move_huge_pud()
to handle the situation properly?

[1] https://lore.kernel.org/linux-ext4/148545012634.17912.13951763606410303827.stgit@djiang5-desk3.ch.intel.com/


—
Best Regards,
Yan, Zi

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

WARNING: multiple messages have this Message-ID (diff)
From: Zi Yan <ziy@nvidia.com>
To: Peter Xu <peterx@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	kaleshsingh@google.com, npiggin@gmail.com,
	Nathan Chancellor <nathan@kernel.org>,
	linux-mm@kvack.org, joel@joelfernandes.org,
	akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5 3/9] mm/mremap: Use pmd/pud_poplulate to update page table entries
Date: Thu, 20 May 2021 15:06:30 -0400	[thread overview]
Message-ID: <4CE7132C-3800-456B-91DA-613391361B94@nvidia.com> (raw)
In-Reply-To: <YKZ49Nrz2OojQUBR@t490s>

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

On 20 May 2021, at 10:57, Peter Xu wrote:

> On Thu, May 20, 2021 at 07:07:57PM +0530, Aneesh Kumar K.V wrote:
>> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>>
>>> On 5/20/21 6:16 PM, Peter Xu wrote:
>>>> On Thu, May 20, 2021 at 01:56:54PM +0530, Aneesh Kumar K.V wrote:
>>>>>> This seems to work at least for my userfaultfd test on shmem, however I don't
>>>>>> fully understand the commit message [1] on: How do we guarantee we're not
>>>>>> moving a thp pte?
>>>>>>
>>>>>
>>>>> move_page_tables() checks for pmd_trans_huge() and ends up calling
>>>>> move_huge_pmd if it is a THP entry.
>>>>
>>>> Sorry to be unclear: what if a huge pud thp?
>>>>
>>>
>>> I am still checking. Looking at the code before commit
>>> c49dd340180260c6239e453263a9a244da9a7c85, I don't see kernel handling
>>> huge pud thp. I haven't studied huge pud thp enough to understand
>>> whether c49dd340180260c6239e453263a9a244da9a7c85 intent to add that
>>> support.
>>>
>>> We can do a move_huge_pud() like we do for huge pmd thp. But I am not
>>> sure whether we handle those VMA's earlier and restrict mremap on them?
>>
>> something like this? (not even compile tested). I am still not sure
>> whether this is really needed or we handle DAX VMA's in some other form.
>
> Yeah maybe (you may want to at least drop that extra "case HPAGE_PUD").
>
> It's just that if with CONFIG_HAVE_MOVE_PUD (x86 and arm64 enables it by
> default so far) it does seem to work even with huge pud, while after this patch
> it seems to be not working anymore, even with your follow up fix.
>
> Indeed I saw CONFIG_HAVE_MOVE_PUD is introduced a few months ago so breaking
> someone seems to be unlikely, perhaps no real user yet to mremap() a huge pud
> for dax or whatever backend?
>
> Ideally maybe rework this patch (or series?) and repost it for a better review?
> Agree the risk seems low.  I'll leave that to you and Andrew to decide..

It seems that the mremap function for 1GB DAX THP was not added when 1GB DAX THP
was implemented[1]. I guess no one is using mremap on 1GB DAX THP. Maybe we want
to at least add a warning or VM_BUG_ON to catch this or use Aneesh’s move_huge_pud()
to handle the situation properly?

[1] https://lore.kernel.org/linux-ext4/148545012634.17912.13951763606410303827.stgit@djiang5-desk3.ch.intel.com/


—
Best Regards,
Yan, Zi

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

  reply	other threads:[~2021-05-20 19:06 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22  5:43 [PATCH v5 0/9] Speedup mremap on ppc64 Aneesh Kumar K.V
2021-04-22  5:43 ` Aneesh Kumar K.V
2021-04-22  5:43 ` [PATCH v5 1/9] selftest/mremap_test: Update the test to handle pagesize other than 4K Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-04-22  5:43 ` [PATCH v5 2/9] selftest/mremap_test: Avoid crash with static build Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-04-22  5:43 ` [PATCH v5 3/9] mm/mremap: Use pmd/pud_poplulate to update page table entries Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-05-18 20:04   ` Nathan Chancellor
2021-05-18 20:04     ` Nathan Chancellor
2021-05-19  4:46     ` Aneesh Kumar K.V
2021-05-19  4:46       ` Aneesh Kumar K.V
2021-05-19 18:02       ` Nathan Chancellor
2021-05-19 18:02         ` Nathan Chancellor
2021-05-20  2:18       ` Peter Xu
2021-05-20  2:18         ` Peter Xu
2021-05-20  8:26         ` Aneesh Kumar K.V
2021-05-20  8:26           ` Aneesh Kumar K.V
2021-05-20 12:46           ` Peter Xu
2021-05-20 12:46             ` Peter Xu
2021-05-20 13:23             ` Aneesh Kumar K.V
2021-05-20 13:23               ` Aneesh Kumar K.V
2021-05-20 13:37               ` Aneesh Kumar K.V
2021-05-20 13:37                 ` Aneesh Kumar K.V
2021-05-20 14:57                 ` Peter Xu
2021-05-20 14:57                   ` Peter Xu
2021-05-20 19:06                   ` Zi Yan [this message]
2021-05-20 19:06                     ` Zi Yan
2021-05-20 20:01                     ` Peter Xu
2021-05-20 20:01                       ` Peter Xu
2021-05-20 20:25                       ` Kalesh Singh
2021-05-20 20:25                         ` Kalesh Singh
2021-04-22  5:43 ` [PATCH v5 4/9] powerpc/mm/book3s64: Fix possible build error Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-04-22  5:43 ` [PATCH v5 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-05-15 16:35   ` Guenter Roeck
2021-05-15 16:35     ` Guenter Roeck
2021-05-15 20:41     ` Andrew Morton
2021-05-15 20:41       ` Andrew Morton
2021-05-15 23:05       ` Guenter Roeck
2021-05-15 23:05         ` Guenter Roeck
2021-05-17  8:40     ` Aneesh Kumar K.V
2021-05-17  8:40       ` Aneesh Kumar K.V
2021-05-17 13:38       ` Guenter Roeck
2021-05-17 13:38         ` Guenter Roeck
2021-05-17 13:55         ` Aneesh Kumar K.V
2021-05-17 13:55           ` Aneesh Kumar K.V
2021-05-17 14:18           ` Guenter Roeck
2021-05-17 14:18             ` Guenter Roeck
2021-05-19  0:26             ` Michael Ellerman
2021-05-19  0:26               ` Michael Ellerman
2021-05-19  0:45               ` Segher Boessenkool
2021-05-19  0:45                 ` Segher Boessenkool
2021-05-19 12:03                 ` Segher Boessenkool
2021-05-19 13:37                   ` Guenter Roeck
2021-05-19 14:20                     ` Segher Boessenkool
2021-05-19 14:20                       ` Segher Boessenkool
2021-05-19 15:28                       ` Guenter Roeck
2021-05-19 15:28                         ` Guenter Roeck
2021-05-20  7:37                   ` Michael Ellerman
2021-05-20 12:17                     ` Segher Boessenkool
2021-05-19  1:08               ` Guenter Roeck
2021-05-19  1:08                 ` Guenter Roeck
2021-05-20 11:38                 ` Michael Ellerman
2021-05-20 11:38                   ` Michael Ellerman
2021-05-20 11:56                   ` Guenter Roeck
2021-05-20 11:56                     ` Guenter Roeck
2021-04-22  5:43 ` [PATCH v5 6/9] mm/mremap: Use range flush that does TLB and page walk cache flush Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-04-22  5:43 ` [PATCH v5 7/9] mm/mremap: Move TLB flush outside page table lock Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-05-20 15:26   ` Aneesh Kumar K.V
2021-05-20 15:26     ` Aneesh Kumar K.V
2021-05-20 16:57     ` Aneesh Kumar K.V
2021-05-20 16:57       ` Aneesh Kumar K.V
2021-05-21  2:40       ` Linus Torvalds
2021-05-21  2:40         ` Linus Torvalds
2021-05-21  3:03         ` Aneesh Kumar K.V
2021-05-21  3:03           ` Aneesh Kumar K.V
2021-05-21  3:28           ` Aneesh Kumar K.V
2021-05-21  3:28             ` Aneesh Kumar K.V
2021-05-21  6:13           ` Linus Torvalds
2021-05-21  6:13             ` Linus Torvalds
2021-05-21 12:50             ` Aneesh Kumar K.V
2021-05-21 12:50               ` Aneesh Kumar K.V
2021-05-21 13:03               ` Aneesh Kumar K.V
2021-05-21 13:03                 ` Aneesh Kumar K.V
2021-05-21 16:03                 ` Linus Torvalds
2021-05-21 16:03                   ` Linus Torvalds
2021-05-21 16:29                   ` Aneesh Kumar K.V
2021-05-21 16:29                     ` Aneesh Kumar K.V
2021-05-24 14:24                   ` Aneesh Kumar K.V
2021-05-24 14:24                     ` Aneesh Kumar K.V
2021-05-21 15:24               ` Liam Howlett
2021-05-21 15:24                 ` Liam Howlett
2021-05-21 16:02                 ` Aneesh Kumar K.V
2021-05-21 16:02                   ` Aneesh Kumar K.V
2021-05-21 16:05                 ` Linus Torvalds
2021-05-21 16:05                   ` Linus Torvalds
2021-04-22  5:43 ` [PATCH v5 8/9] mm/mremap: Allow arch runtime override Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-04-22  5:43 ` [PATCH v5 9/9] powerpc/mm: Enable move pmd/pud Aneesh Kumar K.V
2021-04-22  5:43   ` Aneesh Kumar K.V
2021-05-11 22:19   ` Andrew Morton
2021-05-11 22:19     ` Andrew Morton

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=4CE7132C-3800-456B-91DA-613391361B94@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=joel@joelfernandes.org \
    --cc=kaleshsingh@google.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=nathan@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=peterx@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.