linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>
To: Longlong Xia <xialonglong1@huawei.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linmiaohe@huawei.com" <linmiaohe@huawei.com>,
	"wangkefeng.wang@huawei.com" <wangkefeng.wang@huawei.com>,
	"sunnanyong@huawei.com" <sunnanyong@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 2/2] mm: ksm: Support hwpoison for ksm page
Date: Fri, 31 Mar 2023 05:42:44 +0000	[thread overview]
Message-ID: <20230331054243.GB1435482@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <20230330074501.205092-3-xialonglong1@huawei.com>

On Thu, Mar 30, 2023 at 03:45:01PM +0800, Longlong Xia wrote:
> hwpoison_user_mappings() is updated to support ksm pages, and add
> collect_procs_ksm() to collect processes when the error hit an ksm
> page. The difference from collect_procs_anon() is that it also needs
> to traverse the rmap-item list on the stable node of the ksm page.
> At the same time, add_to_kill_ksm() is added to handle ksm pages. And
> task_in_to_kill_list() is added to avoid duplicate addition of tsk to
> the to_kill list. This is because when scanning the list, if the pages
> that make up the ksm page all come from the same process, they may be
> added repeatedly.
> 
> Signed-off-by: Longlong Xia <xialonglong1@huawei.com>

I don't find any specific issue by code review for now, so I'll try to
test your patches.

I have one comment about duplicated KSM pages.  It seems that KSM controls
page duplication by limiting deduplication factor with max_page_sharing,
primarily for performance reason.  But I think it's imporant from memory
RAS's viewpoint too because that means we could allow recovery from memory
errors on a KSM page by making affected processes to switch to the duplicated
pages (without killing the processes!).  Maybe this might be beyond the scope
of this patchset and I'm not sure how hard it is, but if you are interested
in this issue, that's really nice.

Thanks,
Naoya Horiguchi

  reply	other threads:[~2023-03-31  5:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-30  7:44 [PATCH 0/2] mm: ksm: support " Longlong Xia
2023-03-30  7:45 ` [PATCH 1/2] mm: memory-failure: Refactor add_to_kill() Longlong Xia
2023-03-31  5:41   ` HORIGUCHI NAOYA(堀口 直也)
2023-04-04 10:36     ` xialonglong
2023-04-13  9:26     ` Kefeng Wang
2023-03-30  7:45 ` [PATCH 2/2] mm: ksm: Support hwpoison for ksm page Longlong Xia
2023-03-31  5:42   ` HORIGUCHI NAOYA(堀口 直也) [this message]
2023-04-04 10:42     ` xialonglong
2023-04-13  8:00     ` xialonglong
2023-04-13  9:13       ` HORIGUCHI NAOYA(堀口 直也)
2023-04-13  9:30   ` Kefeng Wang

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=20230331054243.GB1435482@hori.linux.bs1.fc.nec.co.jp \
    --to=naoya.horiguchi@nec.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sunnanyong@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=xialonglong1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox