linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: npiggin@gmail.com, benh@kernel.crashing.org, paulus@samba.org,
	mpe@ellerman.id.au
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: [PATCH v2] powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration
Date: Fri, 22 Feb 2019 22:55:31 +0530	[thread overview]
Message-ID: <20190222172531.16369-1-aneesh.kumar@linux.ibm.com> (raw)

We added runtime allocation of 16G pages in
commit 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.")
That was done to enable 16G allocation on PowerNV and KVM config. In case of KVM
config, we mostly would have the entire guest RAM backed by 16G hugetlb pages for
this to work. PAPR do support partial backing of guest RAM with hugepages via
ibm,expected#pages node of memory node in the device tree. This means rest of the
guest RAM won't be backed by 16G contiguous pages in the host and hence a hash page
table insertion can fail in such case.

An example error message will look like

hash-mmu: mm: Hashing failure ! EA=0x7efc00000000 access=0x8000000000000006 current=readback
hash-mmu:     trap=0x300 vsid=0x67af789 ssize=1 base psize=14 psize 14 pte=0xc000000400000386
readback[12260]: unhandled signal 7 at 00007efc00000000 nip 00000000100012d0 lr 000000001000127c code 2

This patch address that by preventing runtime allocation of 16G hugepages in
LPAR config. To allocate 16G hugetlb one need to kernel command line
hugepagesz=16G hugepages=<number of 16G pages>

With radix translation mode we don't run into this issue.

This change will prevent runtime allocation of 16G hugetlb pages on kvm with
hash translation mode. However, with the current upstream it was observed that
16G hugetlbfs backed guest doesn't boot at all.

We observe boot failure with the below message.
[131354.647546] KVM: map_vrma at 0 failed, ret=-4

That means this patch is not resulting in an observable regression. Once we fix
the boot issue with 16G hugetlb backed memory, we need to use ibm,expected#pages
memory node attribute to indicate 16G page reservation to the guest. This will
also enable partial backing of guest RAM with 16G pages.

Fixes: 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---

Changes from V1:
* update commit message to indicate kvm failure

 arch/powerpc/include/asm/book3s/64/hugetlb.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h b/arch/powerpc/include/asm/book3s/64/hugetlb.h
index 5b0177733994..cd3f2ae0e1e4 100644
--- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
+++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
@@ -35,6 +35,13 @@ static inline int hstate_get_psize(struct hstate *hstate)
 #ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
 static inline bool gigantic_page_supported(void)
 {
+	/*
+	 * We used gigantic page reservation with hypervisor assist in some case.
+	 * We cannot use runtime allocation of gigantic pages in those platforms
+	 * This is hash translation mode LPARs.
+	 */
+	if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
+		return false;
 	return true;
 }
 #endif
-- 
2.20.1


             reply	other threads:[~2019-02-22 17:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 17:25 Aneesh Kumar K.V [this message]
2019-03-14 11:43 ` [v2] powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration Michael Ellerman

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=20190222172531.16369-1-aneesh.kumar@linux.ibm.com \
    --to=aneesh.kumar@linux.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).