From: Andrea Arcangeli <aarcange@redhat.com>
To: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Cc: "Andi Kleen" <andi@firstfloor.org>,
AKPM <akpm@linux-foundation.org>,
"Hidetoshi Seto" <seto.hidetoshi@jp.fujitsu.com>,
"Huang Ying" <ying.huang@intel.com>,
LKLM <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] Avoid unmapping THP when it is failed to be split.
Date: Tue, 25 Jan 2011 23:01:18 +0100 [thread overview]
Message-ID: <20110125220118.GJ926@random.random> (raw)
In-Reply-To: <4D3E6377.6060803@np.css.fujitsu.com>
On Tue, Jan 25, 2011 at 02:45:27PM +0900, Jin Dongming wrote:
> If the THP is failed to be split,
> 1. The processes using the poisoned page could not be collected.
> (Because page_mapped_in_vma() in collect_procs_anon() always
> returns NULL.)
page_mapped_in_vma is only called after split_huge_page without
requiring this change.
> 2. The poisoned page could not be unmapped.
> (If CONFIG_DEBUG_VM is "y", VM_BUG_ON(PageTransHuge(page))
> in try_to_unmap() will be called, and system panic will be
> caused.)
This is more reasonable argument for the change because at times
collect_procs may fail kmalloc or for other reasons kill may be set to
1 without split_huge_page having run.
> 3. The processes using the poisoned page could not be killed, too.
> (Because no process is collected in 1.)
I don't see the point of the change for 1.
> So if splitting THP is failed, it is better to stop unmapping
> rather than causing panic. System might servive if the page is freed
> later.
Splitting THP can't fail unless the page is freed under
split_huge_page (like if the process quits while you're calling
split_huge_page and in turn the anon_vma was already unusable).
Patch looks good but just for point 2.
next prev parent reply other threads:[~2011-01-25 22:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-25 5:45 [PATCH 1/3] Avoid unmapping THP when it is failed to be split Jin Dongming
2011-01-25 22:01 ` Andrea Arcangeli [this message]
2011-01-27 1:12 ` Jin Dongming
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=20110125220118.GJ926@random.random \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=jin.dongming@np.css.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=ying.huang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.