From: Bin Yang <bin.yang@intel.com>
To: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, bin.yang@intel.com, linux-kernel@vger.kernel.org
Subject: [PATCH] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr
Date: Thu, 28 Jun 2018 10:05:40 +0000 [thread overview]
Message-ID: <1530180340-18593-1-git-send-email-bin.yang@intel.com> (raw)
This issue can be easily triggered by free_initmem() functuion on
x86_64 cpu.
When changing page attr, __change_page_attr_set_clr will call
__change_page_attr for every 4K page. And try_preserve_large_page
will be called to check whether it needs to split the large page.
If cpu supports "pdpe1gb", kernel will try to use 1G large page.
In worst case, it needs to check every 4K page in 1G range in
try_preserve_large_page function. If __change_page_attr_set_clr
needs to change lots of 4K pages, cpu will be stuck for long time.
This patch try to cache the last address which had been checked just
now. If the next address is in same big page, the cache will be used
without full range check.
Signed-off-by: Bin Yang <bin.yang@intel.com>
---
arch/x86/mm/pageattr.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 3bded76e..b9241ac 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -552,16 +552,20 @@ static int
try_preserve_large_page(pte_t *kpte, unsigned long address,
struct cpa_data *cpa)
{
+ static unsigned long address_cache;
+ static unsigned long do_split_cache = 1;
unsigned long nextpage_addr, numpages, pmask, psize, addr, pfn, old_pfn;
pte_t new_pte, old_pte, *tmp;
pgprot_t old_prot, new_prot, req_prot;
int i, do_split = 1;
enum pg_level level;
- if (cpa->force_split)
+ spin_lock(&pgd_lock);
+ if (cpa->force_split) {
+ do_split_cache = 1;
return 1;
+ }
- spin_lock(&pgd_lock);
/*
* Check for races, another CPU might have split this page
* up already:
@@ -627,13 +631,25 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
new_prot = static_protections(req_prot, address, pfn);
+ addr = address & pmask;
+ pfn = old_pfn;
+ /*
+ * If an address in same range had been checked just now, re-use the
+ * cache value without full range check. In the worst case, it needs to
+ * check every 4K page in 1G range, which causes cpu stuck for long
+ * time.
+ */
+ if (!do_split_cache &&
+ address_cache >= addr && address_cache < nextpage_addr &&
+ pgprot_val(new_prot) == pgprot_val(old_prot)) {
+ do_split = do_split_cache;
+ goto out_unlock;
+ }
/*
* We need to check the full range, whether
* static_protection() requires a different pgprot for one of
* the pages in the range we try to preserve:
*/
- addr = address & pmask;
- pfn = old_pfn;
for (i = 0; i < (psize >> PAGE_SHIFT); i++, addr += PAGE_SIZE, pfn++) {
pgprot_t chk_prot = static_protections(req_prot, addr, pfn);
@@ -670,6 +686,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
}
out_unlock:
+ address_cache = address;
+ do_split_cache = do_split;
spin_unlock(&pgd_lock);
return do_split;
--
2.7.4
next reply other threads:[~2018-06-28 10:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-28 10:05 Bin Yang [this message]
2018-07-03 13:57 ` Thomas Gleixner
2018-07-04 6:07 ` Yang, Bin
2018-07-04 7:40 ` Thomas Gleixner
2018-07-04 9:16 ` Yang, Bin
2018-07-04 9:20 ` Thomas Gleixner
2018-07-04 10:15 ` Yang, Bin
2018-07-04 14:01 ` Thomas Gleixner
2018-07-05 1:08 ` Yang, Bin
2018-07-05 5:30 ` Thomas Gleixner
2018-07-05 5:48 ` Yang, Bin
2018-07-05 6:15 ` Thomas Gleixner
2018-07-10 2:18 ` Yang, Bin
2018-07-16 7:48 ` Thomas Gleixner
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=1530180340-18593-1-git-send-email-bin.yang@intel.com \
--to=bin.yang@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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
Powered by JetHome