From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9815FC433FE for ; Mon, 7 Nov 2022 02:54:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9B758E0002; Sun, 6 Nov 2022 21:54:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A4C6F8E0001; Sun, 6 Nov 2022 21:54:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 912B98E0002; Sun, 6 Nov 2022 21:54:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7E70E8E0001 for ; Sun, 6 Nov 2022 21:54:05 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 559F7A0BEE for ; Mon, 7 Nov 2022 02:54:05 +0000 (UTC) X-FDA: 80105126850.08.FFB0DA4 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) by imf20.hostedemail.com (Postfix) with ESMTP id C6AB51C0004 for ; Mon, 7 Nov 2022 02:54:04 +0000 (UTC) Received: by mail-pg1-f202.google.com with SMTP id 125-20020a630283000000b0046e9babe7b3so5523243pgc.11 for ; Sun, 06 Nov 2022 18:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=WCZTzcCjMER+e3whDU+fHMKD3ho0SkqXwJLUrVndywI=; b=SITLsjVGr0gi+Y3ANF2Fon424BkbkpHX7WvPZGCX9ydJXEvcnvwNGXzoeWEANS1LOa 9D86qZISvr5iivTqsotApJZ5wVSPZe4cwcq7A4dkqT/oSRIffK5z3rBBVCAK/gwT6g5s c5wkB6+LgegeqCjs/gj0LijfHigyZ2iUiLm169/+kZBw1UG5uk/DtFjoqKBpztl1/Q9q ZUCpL57lRvCaUnR3fbJB/OgcIeyzoFqicfQ3RxREz6QkvM3Ql8VAMDv+TXt5rRz9Fgo7 w/kZ276Rqd50ephtlkHA0Ms2Irs8LXdkKtFkceCAOoRuBhRJlj2BV/8wejhpjJ87x/XJ EBiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WCZTzcCjMER+e3whDU+fHMKD3ho0SkqXwJLUrVndywI=; b=V+SuzMzfHcViyGogmiKKUg8tTM5q7DIMojHAb8Pqdyn7394GCJkei84EFOcEVFt3aL hBJSsfnm7Vi5NE94cWFFR1DjyMsnNIRBIUyyCGzhSb0MIa04vciTzDWGMfI72IxyyukW TPhxrT6OjKdAhJXVNiCYmtUMpdilgnZevuyssswzghYohhCORE5HHcfBKX8WuWhI53D5 PKzaKixK+rE1DO+0LIA5DLVhBsDt6hN6YSn0frLMNScJuBYOWRkC50FDmqqJFymDTmks JoASnna9AZ+mbR1Wmshxvx6u/rCenX58p2OG6kIgkaQoRhJyU92s0oRH9DFWKLNxwPGp QCTQ== X-Gm-Message-State: ANoB5pmx880Ao80ZXv99EqsO8VZu3IwXwSeo56JI904fdcnjcQJGXT5W fiSErTy917DTuyR25j7G7hgRMrs3j5OiqQ== X-Google-Smtp-Source: AA0mqf6Vg0gC06c1k8Kb2XSK7Y4mNHRuIX0xTktXxxIkL3pDwqHr67G0q5mK8XO+qDQWA/aOhZ+fUOZzyuH9oA== X-Received: from yjqkernel.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:1837]) (user=jiaqiyan job=sendgmr) by 2002:a17:90a:f291:b0:20a:eab5:cf39 with SMTP id fs17-20020a17090af29100b0020aeab5cf39mr148444pjb.1.1667789643099; Sun, 06 Nov 2022 18:54:03 -0800 (PST) Date: Sun, 6 Nov 2022 18:53:57 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.38.1.431.g37b22c650d-goog Message-ID: <20221107025359.2911028-1-jiaqiyan@google.com> Subject: [PATCH v6 0/2] Memory poison recovery in khugepaged collapsing From: Jiaqi Yan To: kirill.shutemov@linux.intel.com, kirill@shutemov.name, shy828301@gmail.com, tongtiangen@huawei.com Cc: tony.luck@intel.com, naoya.horiguchi@nec.com, linmiaohe@huawei.com, jiaqiyan@google.com, linux-mm@kvack.org, akpm@linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667789644; a=rsa-sha256; cv=none; b=TPK1IWxzvtJCWme+cQk08H4iefN2+ow/A6BME/tT4TcDlqJnjmDJ7n4pl5/o899CGDrt0+ UtebpW261xg92tKu2bMN3Ed4fZ0v8ozaTaOS96pQqwkyWMmg8/QYjG2ZhDWciqxQG9s7LV 9OiYxLnKzLtaTP9cOB4etMKuF9VVKis= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=SITLsjVG; spf=pass (imf20.hostedemail.com: domain of 3S3NoYwgKCPQfeWmeuWjckkcha.Ykihejqt-iigrWYg.knc@flex--jiaqiyan.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3S3NoYwgKCPQfeWmeuWjckkcha.Ykihejqt-iigrWYg.knc@flex--jiaqiyan.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667789644; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=WCZTzcCjMER+e3whDU+fHMKD3ho0SkqXwJLUrVndywI=; b=37z0JbkgToWwtcAgtGNhe5mAEn2iN84t4cZ4t/qWg1ZvpN8WatjIeKzXGjcUE0uKAkCGM9 j2dYnCq+Dv9bHV6iU+ydIVjoZu00cFaijFCjnYCZcrL1IRVrovtfTl8kB0NT5Cf4ML+VZG 6mWXWCcrLDZt8CkY7b+NJ7P1RoGpLdo= X-Stat-Signature: km8t6o3kskymzb193ddkzwjd3juoww4g X-Rspamd-Queue-Id: C6AB51C0004 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=SITLsjVG; spf=pass (imf20.hostedemail.com: domain of 3S3NoYwgKCPQfeWmeuWjckkcha.Ykihejqt-iigrWYg.knc@flex--jiaqiyan.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3S3NoYwgKCPQfeWmeuWjckkcha.Ykihejqt-iigrWYg.knc@flex--jiaqiyan.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1667789644-445702 X-Bogosity: Ham, tests=bogofilter, spamicity=0.009085, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Problem =3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D 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=E2=80=99s compaction operations are not functionally re= quired 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 =3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D v6 changes - Address comments from Kirill Shutemov - 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 - 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 - 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 - 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/linux/highmem.h | 19 +++ include/trace/events/huge_memory.h | 3 +- mm/khugepaged.c | 233 ++++++++++++++++++++--------- 3 files changed, 183 insertions(+), 72 deletions(-) --=20 2.38.1.431.g37b22c650d-goog