From: "Zach O'Keefe" <zokeefe@google.com>
To: Xu Yu <xuyu@linux.alibaba.com>
Cc: linux-mm@kvack.org, david@redhat.com
Subject: Re: [PATCH v3 0/2] attempt to map anonymous pte-mapped THPs by pmds
Date: Thu, 21 Dec 2023 12:40:49 -0800 [thread overview]
Message-ID: <CAAa6QmSL=Gm0ePv7bCu72wbx_dUDjkcSarcdOXhFQWPjOyH1vg@mail.gmail.com> (raw)
In-Reply-To: <cover.1702882426.git.xuyu@linux.alibaba.com>
Hey Xu,
Thanks for the patches.
As a precursor, can you help understand what the use case is for these
patches? In-place collapse of anon memory is something I've thought
about before, but the opportunity has never been especially clear.
In particular, your patches take an order-9 compound page, and just
try to see if we can update the mappings to it (like we do with
file/shmem). Functionally this seems fine, but the difference is that
with file/shmem, it's quite easy to have a pte-mapped-hugepage arise
naturally (the formation of the hugepage happening in the pagecache
being logically separate from the pmd-mapping of w/e task is mapping
it).\
For anonymous memory, the only time I can see us having a pte-mapped
hugepage (that isn't destined for splitting on deferred split list)
that we want to remap by a pmd is if we cause a VMA split + remerge by
mucking with VMA attributes.
In my mind, what I had been thinking of w.r.t in-place anon collapse
was for the case where we've split a THP with MADV_FREE/MADV_DONTNEED
(i.e. to subrelease pages back to kernel), but later want to reform
the THP. In particular, if, for example, we only subrelease O(10s) of
order-0 pages, it seems wasteful to have to reallocate a fresh
hugepage, then copy over O(100s) of pages, on collapse. If we were
able to attempt to first migrate-away any of those previously
subreleased pages (now possibly backing some other memory entirely),
it could save us from having to allocate a fresh order-9 page. Under
memory pressure / fragmentation, this could mean the difference
between success and failure.
Thanks for your help here,
Zach
On Sun, Dec 17, 2023 at 11:06 PM Xu Yu <xuyu@linux.alibaba.com> wrote:
>
> Result of tools/testing/selftests/mm/cow.c tests:
> # [RUN] Basic COW after fork() when collapsing before fork()
> ok 145 No leak from parent into child
> # [RUN] Basic COW after fork() when collapsing after fork() (fully shared)
> ok 146 No leak from parent into child
> # [RUN] Basic COW after fork() when collapsing after fork() (lower shared)
> ok 147 No leak from parent into child
> # [RUN] Basic COW after fork() when collapsing after fork() (upper shared)
> ok 148 No leak from parent into child
>
> A long run (w/ CONFIG_DEBUG_VM enabled) shows no panic or memory leaks.
>
> Changes since v2:
> - Use folios in the new code, as suggested by David.
> - Handle folio refcount and rmap properly, as suggested by David.
> - minor modification includes 1) advance vma write lock, 2) remove
> redundant rollback logic, 3) clear old ptes in pgtable before deposit.
>
> Changes since v1:
> - Deal with PageAnonExclusive properly, as suggested by David.
>
> Xu Yu (2):
> mm/khugepaged: map RO non-exclusive pte-mapped anon THPs by pmds
> mm/khugepaged: map exclusive anonymous pte-mapped THPs by pmds
>
> mm/khugepaged.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 229 insertions(+)
>
> --
> 2.37.1
>
>
next prev parent reply other threads:[~2023-12-21 20:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 9:05 [PATCH 0/1] mm/khugepaged: " Xu Yu
2023-11-13 9:05 ` [PATCH 1/1] " Xu Yu
2023-11-13 9:26 ` David Hildenbrand
2023-11-13 9:33 ` Xu Yu
2023-11-13 10:10 ` David Hildenbrand
2023-12-07 3:09 ` [PATCH v2 0/2] attempt to " Xu Yu
2023-12-07 3:09 ` [PATCH v2 1/2] mm/khugepaged: " Xu Yu
2023-12-07 7:47 ` Xu Yu
2023-12-07 10:37 ` David Hildenbrand
2023-12-18 2:45 ` Xu Yu
2023-12-07 3:09 ` [PATCH v2 2/2] mm/khugepaged: add case for mapping " Xu Yu
2023-12-18 7:06 ` [PATCH v3 0/2] attempt to map " Xu Yu
2023-12-18 7:06 ` [PATCH v3 1/2] mm/khugepaged: map RO non-exclusive pte-mapped anon " Xu Yu
2023-12-18 7:06 ` [PATCH v3 2/2] mm/khugepaged: map exclusive anonymous pte-mapped " Xu Yu
2023-12-21 20:40 ` Zach O'Keefe [this message]
2023-12-21 20:54 ` [PATCH v3 0/2] attempt to map " David Hildenbrand
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='CAAa6QmSL=Gm0ePv7bCu72wbx_dUDjkcSarcdOXhFQWPjOyH1vg@mail.gmail.com' \
--to=zokeefe@google.com \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=xuyu@linux.alibaba.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