New: hugetlbfs: disabling because there are no supported hugepage sizes

Bug 119641 Andrew Morton 3 participants 3 messages Jun 6, 2016 – Jun 8, 2016 1 message not in the archive Memory management

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author maintainer

2016-06-06 21:01 UTC #1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Does anyone have any theories about this? I went through the 4.5.2->4.5.5 changelog searching for "huget" but came up blank..

I'm suspiciously staring at Ingo's change

commit b2eafe890d4a09bfa63ab31ff018d7d6bb8cfefc

Merge: abfb949 ea5dfb5
Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri Apr 22 10:12:19 2016 +0200
Commit:     Ingo Molnar <[email protected]>
CommitDate: Fri Apr 22 10:13:53 2016 +0200

Merge branch 'x86/urgent' into x86/asm, to fix semantic conflict

'cpu_has_pse' has changed to boot_cpu_has(X86_FEATURE_PSE), fix this up in the merge commit when merging the x86/urgent tree that includes the following commit:

103f6112f253 ("x86/mm/xen: Suppress hugetlbfs in PV guests")

Signed-off-by Ingo Molnar <[email protected]>

--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@@ -4,6 -4,7 +4,7 @@@
#include <asm/page.h>
#include <asm-generic/hugetlb.h>

-#define hugepages_supported() cpu_has_pse
++#define hugepages_supported() boot_cpu_has(X86_FEATURE_PSE)

static inline int is_hugepage_only_range(struct mm_struct *mm,
unsigned long addr,

Which is a followon to Jan's

y:/usr/src/git26> gitshow 103f6112f253
commit 103f6112f253017d7062cd74d17f4a514ed4485c

Author:     Jan Beulich <[email protected]>
AuthorDate: Thu Apr 21 00:27:04 2016 -0600
Commit:     Ingo Molnar <[email protected]>
CommitDate: Fri Apr 22 10:05:00 2016 +0200

x86/mm/xen: Suppress hugetlbfs in PV guests

Huge pages are not normally available to PV guests. Not suppressing hugetlbfs use results in an endless loop of page faults when user mode code tries to access a hugetlbfs mapped area (since the hypervisor denies such PTEs to be created, but error indications can't be propagated out of xen_set_pte_at(), just like for various of its siblings), and - once killed in an oops like this:

Quoted 46 lines · On Sat, 04 Jun 2016 17:08:36 +0000 [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=119641
            Bug ID: 119641
           Summary: hugetlbfs: disabling because there are no supported
                    hugepage sizes
           Product: Memory Management
           Version: 2.5
    Kernel Version: 3.6.1
          Hardware: Intel
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No
Created attachment 219011
--> https://bugzilla.kernel.org/attachment.cgi?id=219011&action=edit
.config for 4.6.1 kernel
Hello,
I get a message while starting the 4.6.1 kernel under Xen :
hugetlbfs: disabling because there are no supported hugepage sizes
And after grepping /proc/meminfo for Huge I get only :
grep -i huge /proc/meminfo
AnonHugePages: 0 kB
I get this message only when starting the kernel under Xen, when starting kernel alone All is OK and I get the "normal" hugepages list.
I test some previous kernels versions :
4.5.2   OK
4.5.5   KO
4.6.0   KO
My system is
CPU     Intel Core I7 6700
MEM     32Go
Disks   some ...
System  Debian unstable up to date

Quoted 9 lines

I enclose the .config file.
Regards
JP P
Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Jan Beulich

2016-06-07 06:43 UTC #2 lore raw

Quoted 3 lines

Quoted 1 line
Quoted 1 line · On 06.06.16 at 23:01, <[email protected]> wrote:
Does anyone have any theories about this? I went through the 4.5.2->4.5.5 changelog searching for "huget" but came up blank..

Well, the original report (still quoted below) doesn't say whether that's a PV or HVM guest under Xen (not that from the .config one cannot tell). In the former case, observed behavior is the intended effect of commit 103f6112f2: There simply are no huge pages available in that environment. In the latter case I can't see where the problem would be coming from.

Jan

Quoted 51 lines

I'm suspiciously staring at Ingo's change
commit b2eafe890d4a09bfa63ab31ff018d7d6bb8cfefc
Merge: abfb949 ea5dfb5
Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri Apr 22 10:12:19 2016 +0200
Commit:     Ingo Molnar <[email protected]>
CommitDate: Fri Apr 22 10:13:53 2016 +0200
Merge branch 'x86/urgent' into x86/asm, to fix semantic conflict
'cpu_has_pse' has changed to boot_cpu_has(X86_FEATURE_PSE), fix this up in the merge commit when merging the x86/urgent tree that includes the following commit:
103f6112f253 ("x86/mm/xen: Suppress hugetlbfs in PV guests")
Signed-off-by Ingo Molnar <[email protected]>
arch/x86/include/asm/hugetlb.h +1 -0
@@@ -4,6 -4,7 +4,7 @@@
  #include <asm/page.h>
  #include <asm-generic/hugetlb.h>
 
 -#define hugepages_supported() cpu_has_pse
++#define hugepages_supported() boot_cpu_has(X86_FEATURE_PSE)
 
  static inline int is_hugepage_only_range(struct mm_struct *mm,
                                         unsigned long addr,
Which is a followon to Jan's
y:/usr/src/git26> gitshow 103f6112f253
commit 103f6112f253017d7062cd74d17f4a514ed4485c
Author:     Jan Beulich <[email protected]>
AuthorDate: Thu Apr 21 00:27:04 2016 -0600
Commit:     Ingo Molnar <[email protected]>
CommitDate: Fri Apr 22 10:05:00 2016 +0200
x86/mm/xen: Suppress hugetlbfs in PV guests
Huge pages are not normally available to PV guests. Not suppressing hugetlbfs use results in an endless loop of page faults when user mode code tries to access a hugetlbfs mapped area (since the hypervisor denies such PTEs to be created, but error indications can't be propagated out of xen_set_pte_at(), just like for various of its siblings), and - once killed in an oops like this:

Quoted 57 lines

Quoted 55 lines · On Sat, 04 Jun 2016 17:08:36 +0000 [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=119641
            Bug ID: 119641
           Summary: hugetlbfs: disabling because there are no supported
                    hugepage sizes
           Product: Memory Management
           Version: 2.5
    Kernel Version: 3.6.1
          Hardware: Intel
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: [email protected] 
          Reporter: [email protected] 
        Regression: No
Created attachment 219011
--> https://bugzilla.kernel.org/attachment.cgi?id=219011&action=edit
.config for 4.6.1 kernel
Hello,
I get a message while starting the 4.6.1 kernel under Xen :
hugetlbfs: disabling because there are no supported hugepage sizes
And after grepping /proc/meminfo for Huge I get only :
grep -i huge /proc/meminfo
AnonHugePages: 0 kB
I get this message only when starting the kernel under Xen, when starting kernel alone All is OK and I get the "normal" hugepages list.
I test some previous kernels versions :
4.5.2   OK
4.5.5   KO
4.6.0   KO
My system is
CPU     Intel Core I7 6700
MEM     32Go
Disks   some ...
System  Debian unstable up to date
I enclose the .config file.
Regards
JP P
Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.

Ingo Molnar

2016-06-08 08:42 UTC #3 lore raw

In reply to Andrew Morton

Quoted 29 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Does anyone have any theories about this? I went through the 4.5.2->4.5.5 changelog searching for "huget" but came up blank..
I'm suspiciously staring at Ingo's change
commit b2eafe890d4a09bfa63ab31ff018d7d6bb8cfefc
Merge: abfb949 ea5dfb5
Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri Apr 22 10:12:19 2016 +0200
Commit:     Ingo Molnar <[email protected]>
CommitDate: Fri Apr 22 10:13:53 2016 +0200
Merge branch 'x86/urgent' into x86/asm, to fix semantic conflict
'cpu_has_pse' has changed to boot_cpu_has(X86_FEATURE_PSE), fix this up in the merge commit when merging the x86/urgent tree that includes the following commit:
103f6112f253 ("x86/mm/xen: Suppress hugetlbfs in PV guests")
Signed-off-by Ingo Molnar <[email protected]>

arch/x86/include/asm/hugetlb.h

Quoted 5 lines

arch/x86/include/asm/hugetlb.h +1 -0

@@@ -4,6 -4,7 +4,7 @@@
  #include <asm/page.h>
  #include <asm-generic/hugetlb.h>
 
 -#define hugepages_supported() cpu_has_pse
++#define hugepages_supported() boot_cpu_has(X86_FEATURE_PSE)

That's really a no-op change, as we simply got rid of cpu_has_pse:

-#define cpu_has_pse boot_cpu_has(X86_FEATURE_PSE)

... and open coded the boot_cpu_has(X86_FEATURE_PSE) uses. There should be zero change to the generated code.

Thanks,

Ingo