From: Mike Kravetz <mike.kravetz@oracle.com>
To: Jiaqi Yan <jiaqiyan@google.com>
Cc: songmuchun@bytedance.com, naoya.horiguchi@nec.com,
shy828301@gmail.com, linmiaohe@huawei.com,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, duenwen@google.com,
axelrasmussen@google.com, jthoughton@google.com
Subject: Re: [PATCH v1 0/3] Improve hugetlbfs read on HWPOISON hugepages
Date: Wed, 17 May 2023 16:30:20 -0700 [thread overview]
Message-ID: <20230517233020.GA10757@monkey> (raw)
In-Reply-To: <20230517160948.811355-1-jiaqiyan@google.com>
On 05/17/23 16:09, Jiaqi Yan wrote:
> Today when hardware memory is corrupted in a hugetlb hugepage,
> kernel leaves the hugepage in pagecache [1]; otherwise future mmap or
> read will suject to silent data corruption. This is implemented by
> returning -EIO from hugetlb_read_iter immediately if the hugepage has
> HWPOISON flag set.
>
> Since memory_failure already tracks the raw HWPOISON subpages in a
> hugepage, a natural improvement is possible: if userspace only asks for
> healthy subpages in the pagecache, kernel can return these data.
Thanks for putting this together.
I recall discussing this some time back, and deciding to wait and see
how HGM would progress. Since it may be some time before HGM goes
upstream, it would be reasonable to consider this again.
One quick question.
Do you have an actual use case for this? It certainly is an improvement
over existing functionality. However, I am not aware of too many (?any?)
users actually doing read() calls on hugetlb files.
--
Mike Kravetz
> This patchset implements this improvement. It consist of three parts.
> The 1st commit exports the functionality to tell if a subpage inside a
> hugetlb hugepage is a raw HWPOISON page. The 2nd commit teaches
> hugetlbfs_read_iter to return as many healthy bytes as possible.
> The 3rd commit properly tests this new feature.
>
> [1] commit 8625147cafaa ("hugetlbfs: don't delete error page from pagecache")
>
> Jiaqi Yan (3):
> mm/hwpoison: find subpage in hugetlb HWPOISON list
> hugetlbfs: improve read HWPOISON hugepage
> selftests/mm: add tests for HWPOISON hugetlbfs read
>
> fs/hugetlbfs/inode.c | 62 +++-
> include/linux/mm.h | 23 ++
> mm/memory-failure.c | 26 +-
> tools/testing/selftests/mm/.gitignore | 1 +
> tools/testing/selftests/mm/Makefile | 1 +
> .../selftests/mm/hugetlb-read-hwpoison.c | 322 ++++++++++++++++++
> 6 files changed, 419 insertions(+), 16 deletions(-)
> create mode 100644 tools/testing/selftests/mm/hugetlb-read-hwpoison.c
>
> --
> 2.40.1.606.ga4b1b128d6-goog
>
next prev parent reply other threads:[~2023-05-17 23:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 16:09 [PATCH v1 0/3] Improve hugetlbfs read on HWPOISON hugepages Jiaqi Yan
2023-05-17 16:09 ` [PATCH v1 1/3] mm/hwpoison: find subpage in hugetlb HWPOISON list Jiaqi Yan
2023-05-17 23:53 ` Mike Kravetz
2023-05-19 20:54 ` Jiaqi Yan
2023-05-19 22:42 ` Mike Kravetz
2023-05-22 4:50 ` HORIGUCHI NAOYA(堀口 直也)
2023-05-22 18:22 ` Jiaqi Yan
2023-05-23 2:43 ` HORIGUCHI NAOYA(堀口 直也)
2023-05-26 0:28 ` Jiaqi Yan
2023-06-10 5:48 ` Jiaqi Yan
2023-06-12 4:19 ` Naoya Horiguchi
2023-06-16 21:19 ` Jiaqi Yan
2023-06-16 23:34 ` Mike Kravetz
2023-06-17 2:18 ` Jiaqi Yan
2023-06-17 22:59 ` Mike Kravetz
2023-06-19 8:23 ` Naoya Horiguchi
2023-06-20 18:05 ` Mike Kravetz
2023-06-20 22:39 ` Mike Kravetz
2023-06-23 0:45 ` Jiaqi Yan
2023-06-23 4:19 ` Mike Kravetz
2023-06-23 16:40 ` Jiaqi Yan
2023-05-17 16:09 ` [PATCH v1 2/3] hugetlbfs: improve read HWPOISON hugepage Jiaqi Yan
2023-05-18 22:18 ` Mike Kravetz
2023-05-19 20:54 ` Jiaqi Yan
2023-05-17 16:09 ` [PATCH v1 3/3] selftests/mm: add tests for HWPOISON hugetlbfs read Jiaqi Yan
2023-05-23 7:35 ` kernel test robot
2023-05-17 23:30 ` Mike Kravetz [this message]
2023-05-18 16:02 ` [PATCH v1 0/3] Improve hugetlbfs read on HWPOISON hugepages Jiaqi Yan
2023-05-18 16:10 ` Jiaqi Yan
2023-05-18 22:24 ` Mike Kravetz
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=20230517233020.GA10757@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=duenwen@google.com \
--cc=jiaqiyan@google.com \
--cc=jthoughton@google.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=naoya.horiguchi@nec.com \
--cc=shy828301@gmail.com \
--cc=songmuchun@bytedance.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;
as well as URLs for NNTP newsgroup(s).