From: Jiaqi Yan <jiaqiyan@google.com>
To: Mike Kravetz <mike.kravetz@oracle.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: Thu, 18 May 2023 09:10:39 -0700 [thread overview]
Message-ID: <CACw3F51iVe7AtaFDR_y1x+hc8HH1nAqKA7ZYtL=tte6Qmb5CGg@mail.gmail.com> (raw)
In-Reply-To: <20230517233020.GA10757@monkey>
On Wed, May 17, 2023 at 4:30 PM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> 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.
This improvement actually does NOT depend on HGM at all. No page table
related stuff involved here. The other RFC [2] I sent earlier DOES
require HGM. This improvement was brought up by James when we were
working on [2]. In "Future Work" section of the cover letter, I
thought HGM was needed but soon when I code it up, I found I was
wrong.
>
> 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.
I don't have any use case. I did search on Github for around half a
hour and all the hugetlb usages are done via mmap.
> --
> 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")
[2] https://lore.kernel.org/linux-mm/20230428004139.2899856-6-jiaqiyan@google.com/T/#m97c6edef8ad0cc9b064e1fd9369b8521dcfa43de
> >
> > 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
> >
(Sorry if you received twice, was sent in a wrong way a while ago)
next prev parent reply other threads:[~2023-05-18 16:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 16:09 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 ` [PATCH v1 0/3] Improve hugetlbfs read on HWPOISON hugepages Mike Kravetz
2023-05-18 16:02 ` Jiaqi Yan
2023-05-18 16:10 ` Jiaqi Yan [this message]
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='CACw3F51iVe7AtaFDR_y1x+hc8HH1nAqKA7ZYtL=tte6Qmb5CGg@mail.gmail.com' \
--to=jiaqiyan@google.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=duenwen@google.com \
--cc=jthoughton@google.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--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