All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiaqi Yan <jiaqiyan@google.com>
To: kirill.shutemov@linux.intel.com, kirill@shutemov.name,
	shy828301@gmail.com,  tongtiangen@huawei.com,
	tony.luck@intel.com, akpm@linux-foundation.org,
	 wangkefeng.wang@huawei.com
Cc: naoya.horiguchi@nec.com, linmiaohe@huawei.com,
	jiaqiyan@google.com,  linux-mm@kvack.org, osalvador@suse.de
Subject: [PATCH v9 0/2] Memory poison recovery in khugepaged collapsing
Date: Mon,  5 Dec 2022 15:40:57 -0800	[thread overview]
Message-ID: <20221205234059.42971-1-jiaqiyan@google.com> (raw)

Problem
=======
Memory DIMMs are subject to multi-bit flips, i.e. memory errors.
As memory size and density increase, the chances of and number of
memory errors increase. The increasing size and density of server
RAM in the data center and cloud have shown increased uncorrectable
memory errors. There are already mechanisms in the kernel to recover
from uncorrectable memory errors. This series of patches provides
the recovery mechanism for the particular kernel agent khugepaged
when it collapses memory pages.

Impact
======
The main reason we chose to make khugepaged collapsing tolerant of
memory failures was its high possibility of accessing poisoned memory
while performing functionally optional compaction actions.
Standard applications typically don't have strict requirements on
the size of its pages. So they are given 4K pages by the kernel.
The kernel is able to improve application performance by either

  1) giving applications 2M pages to begin with, or
  2) collapsing 4K pages into 2M pages when possible.

This collapsing operation is done by khugepaged, a kernel agent that
is constantly scanning memory. When collapsing 4K pages into a 2M page,
it must copy the data from the 4K pages into a physically contiguous
2M page. Therefore, as long as there exists one poisoned cache line in
collapsible 4K pages, khugepaged will eventually access it. The current
impact to users is a machine check exception triggered kernel panic.
However, khugepaged’s compaction operations are not functionally required
kernel actions. Therefore making khugepaged tolerant to poisoned memory
will greatly improve user experience.

This patch series is for cases where khugepaged is the first guy
that detects the memory errors on the poisoned pages. IOW, the pages
are not known to have memory errors when khugepaged collapsing gets to
them. In our observation, this happens frequently when the huge page
ratio of the system is relatively low, which is fairly common in
virtual machines running on cloud.

Solution
========
As stated before, it is less desirable to crash the system only because
khugepaged accesses poisoned pages while it is collapsing 4K pages.
The high level idea of this patch series is to skip the group of pages
(usually 512 4K-size pages) once khugepaged finds one of them is poisoned,
as these pages have become ineligible to be collapsed.

We are also careful to unwind operations khuagepaged has performed before
it detects memory failures. For example, before copying and collapsing
a group of anonymous pages into a huge page, the source pages will be
isolated and their page table is unlinked from their PMD. These operations
need to be undone in order to ensure these pages are not changed/lost from
the perspective of other threads (both user and kernel space). As for
file backed memory pages, there already exists a rollback case. This
patch just extends it so that khugepaged also correctly rolls back when
it fails to copy poisoned 4K pages.

Changelog
=========

v9 changes
- Incorporate feedback from Andrew Morton <akpm@linux-foundation.org>
- Move copy_mc_highpage into khugepage.c as a static out-of-line
  function copy_mc_page.

v8 changes
- Incorporate feedbacks from Tony Luck <tony.luck@intel.com>
- Rename copy_highpage_mc to copy_mc_highpage.
- Update copy_mc_highpage with kmsan changes.
- Code style changes:
  1) copy_mc_highpage returns int as "copy" is an action and is consistent
     with copy_mc_user_highpage.
  2) __collapse_huge_page_copy returns scan_result(int) and is consistent
     with __collapse_huge_page_isolate/swapin.
  3) variables are declared in separate lines in collapse_file.

v7 changes
- Fix a bug "KASAN: stack-out-of-bounds Read in collapse_file". After copying
  all pages into the huge page, clear_highpage should use `index` instead of
  `page->index`.

v6 changes
- Address comments from Kirill Shutemov <kirill@shutemov.name>
- Rewrite __collapse_huge_page_copy to make rollback operations more
  clear to its reader.
- Add detailed test steps in each commit message.

v5 changes
- Rebase patches to mm-unstable at
  commit ffb39098bf87 ("Merge tag 'linux-kselftest-kunit-6.1-rc1' of
  git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest").
- Resolves conflicts with:
  commit 2f55f070e5b8 ("mm/khugepaged: minor cleanup for collapse_file")
  commit 1baec203b77c ("mm/khugepaged: try to free transhuge swapcache
  when possible")

v4 changes
- Incorporate feedbacks from Yang Shi <shy828301@gmail.com>
- Remove tracepoint for __collapse_huge_page_copy, just keep SCAN_COPY_MC
  and let trace_mm_collapse_huge_page it
- Remove unnecessary comments

v3 changes
- Incorporate feedbacks from Yang Shi <shy828301@gmail.com>
- Add tracepoint for __collapse_huge_page_copy
- Restore PMD in collapse_huge_page
- Correct comment about mmap_read_lock

v2 changes
- Incorporate feedbacks from Yang Shi <shy828301@gmail.com>
- Only keep copy_highpage_mc
- Adding new scan_result SCAN_COPY_MC
- Defer NR_FILE_THPS update until copying succeeded

Jiaqi Yan (2):
  mm/khugepaged: recover from poisoned anonymous memory
  mm/khugepaged: recover from poisoned file-backed memory

 include/trace/events/huge_memory.h |   3 +-
 mm/khugepaged.c                    | 257 +++++++++++++++++++++--------
 2 files changed, 187 insertions(+), 73 deletions(-)

-- 
2.39.0.rc0.267.gcb52ba06e7-goog



             reply	other threads:[~2022-12-05 23:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 23:40 Jiaqi Yan [this message]
2022-12-05 23:40 ` [PATCH v9 1/2] mm/khugepaged: recover from poisoned anonymous memory Jiaqi Yan
2023-01-19 15:02   ` kirill.shutemov
2023-01-20 15:56     ` Jiaqi Yan
2023-01-24  0:33       ` kirill.shutemov
2023-02-01  5:16         ` Jiaqi Yan
2023-02-02  0:01           ` kirill.shutemov
2023-02-02  0:30             ` kirill
2023-02-07 18:19               ` Jiaqi Yan
2023-02-08 11:44                 ` Alexander Potapenko
2023-02-08 23:00                   ` Jiaqi Yan
2023-02-17 19:49                     ` Jiaqi Yan
2023-02-28 13:40                     ` kirill
2023-03-03 17:15                       ` Jiaqi Yan
2022-12-05 23:40 ` [PATCH v9 2/2] mm/khugepaged: recover from poisoned file-backed memory Jiaqi Yan
2023-01-19 15:10   ` kirill.shutemov
2023-01-19 21:24     ` Jiaqi Yan
2023-01-18 23:29 ` [PATCH v9 0/2] Memory poison recovery in khugepaged collapsing 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=20221205234059.42971-1-jiaqiyan@google.com \
    --to=jiaqiyan@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linmiaohe@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=osalvador@suse.de \
    --cc=shy828301@gmail.com \
    --cc=tongtiangen@huawei.com \
    --cc=tony.luck@intel.com \
    --cc=wangkefeng.wang@huawei.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.