From: "yaoaili [么爱利]" <yaoaili@kingsoft.com>
To: "HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>,
"Oscar Salvador" <osalvador@suse.de>
Cc: "yaoaili126@163.com" <yaoaili126@163.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"YANGFENG1 [杨峰]" <YANGFENG1@kingsoft.com>,
"willy@infradead.org" <willy@infradead.org>
Subject: RE: [PATCH] Fix incorrect compound page flags store
Date: Tue, 8 Sep 2020 08:48:21 +0000 [thread overview]
Message-ID: <d887264d97c24f8ebd7aa3b34b189f19@kingsoft.com> (raw)
In-Reply-To: <20200908083630.GA15481@hori.linux.bs1.fc.nec.co.jp>
Does the if (PageCompound(p) && compound_head(p) != orig_head) check cover the case you mentioned?
Thanks
-----Original Message-----
From: HORIGUCHI NAOYA(堀口 直也) [mailto:naoya.horiguchi@nec.com]
Sent: Tuesday, September 8, 2020 4:37 PM
To: Oscar Salvador <osalvador@suse.de>
Cc: yaoaili126@163.com; linux-mm@kvack.org; YANGFENG1 [杨峰] <YANGFENG1@kingsoft.com>; yaoaili [么爱利] <yaoaili@kingsoft.com>; willy@infradead.org
Subject: Re: [PATCH] Fix incorrect compound page flags store
On Tue, Sep 08, 2020 at 09:26:13AM +0200, Oscar Salvador wrote:
> On Tue, Sep 08, 2020 at 07:02:12AM +0000, HORIGUCHI NAOYA(堀口 直也) wrote:
> > On Mon, Sep 07, 2020 at 08:44:42PM -0700, yaoaili126@163.com wrote:
> > > From: Aili Yao <yaoaili@kingsoft.com>
> > >
> > > PageHuge(p) branch will never be true,but for compound page we need to set page_flags to correct value.
> > >
> > > Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > > Signed-off-by: Yang Feng < yangfeng1@kingsoft.com>
> > > Signed-off-by: Aili Yao <yaoaili@kingsoft.com>
> >
> > I found that this PageHuge() check is removed and no long exists in
> > the latest mmotm, so we don't have worry about it.
>
> I might be missing something, so bear with me.
>
> It is true that the PageHuge check is gone, but we are storing the
> page's flags in page_flags, even if the page is a tail (e.g: part of a
> compound page ).
> Should not we store heads' flags instead?
I think that saving ->flags of the raw error page is OK, because even in thp case we focus on the raw page instead of its head page from memory error perspective. It's not assumed that we can contain the error thp in the thp unit and instead we always rely on thp split. (For hugetlb, we now contain the errored hugetlb in hugetlb unit, so saving its head page might be OK.)
Theoretically, it could happen that a error could be collapsed into a new thp just after passing over the following block:
1408 if (PageTransHuge(hpage)) {
1409 if (try_to_split_thp_page(p, "Memory Failure") < 0) {
1410 action_result(pfn, MF_MSG_UNSPLIT_THP, MF_IGNORED);
1411 return -EBUSY;
1412 }
1413 VM_BUG_ON_PAGE(!page_count(p), p);
1414 }
So I feel that some check might be added after holding page lock to avoid that case. Or acutally, it might better that moving the above block into page lock is more better for simpler code.
Thanks,
Naoya Horiguchi
> AFAICS, hpage contains either the head of the compound page, or the
> page itself in case it is a normal page.
>
> --
> Oscar Salvador
> SUSE L3
>
next prev parent reply other threads:[~2020-09-08 8:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 3:44 yaoaili126
2020-09-08 7:02 ` HORIGUCHI NAOYA(堀口 直也)
2020-09-08 7:18 ` yaoaili [么爱利]
2020-09-08 7:26 ` Oscar Salvador
2020-09-08 8:02 ` yaoaili [么爱利]
2020-09-08 8:09 ` Oscar Salvador
2020-09-08 8:36 ` HORIGUCHI NAOYA(堀口 直也)
2020-09-08 8:48 ` yaoaili [么爱利] [this message]
2020-09-08 9:00 ` HORIGUCHI NAOYA(堀口 直也)
2020-09-08 9:10 ` yaoaili [么爱利]
2020-09-08 8:51 ` Oscar Salvador
2020-09-08 9:05 ` HORIGUCHI NAOYA(堀口 直也)
2020-09-18 9:35 ` Oscar Salvador
2020-09-25 1:18 ` HORIGUCHI NAOYA(堀口 直也)
2020-09-25 1:55 ` yaoaili [么爱利]
2020-09-25 4:35 ` HORIGUCHI NAOYA(堀口 直也)
2020-09-25 5:52 ` yaoaili [么爱利]
-- strict thread matches above, loose matches on Subject: below --
2020-09-02 11:24 [PATCH] fix " yaoaili [么爱利]
2020-09-02 11:35 ` Matthew Wilcox
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=d887264d97c24f8ebd7aa3b34b189f19@kingsoft.com \
--to=yaoaili@kingsoft.com \
--cc=YANGFENG1@kingsoft.com \
--cc=linux-mm@kvack.org \
--cc=naoya.horiguchi@nec.com \
--cc=osalvador@suse.de \
--cc=willy@infradead.org \
--cc=yaoaili126@163.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