>>> On 06.06.16 at 23:01, <akpm@xxxxxxxxxxxxxxxxxxxx> 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
> I'm suspiciously staring at Ingo's change
>
> commit b2eafe890d4a09bfa63ab31ff018d7d6bb8cfefc
> Merge: abfb949 ea5dfb5
> Author: Ingo Molnar <mingo@xxxxxxxxxx>
> AuthorDate: Fri Apr 22 10:12:19 2016 +0200
> Commit: Ingo Molnar <mingo@xxxxxxxxxx>
> 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 <mingo@xxxxxxxxxx>
>
> --- 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 <JBeulich@xxxxxxxx>
> AuthorDate: Thu Apr 21 00:27:04 2016 -0600
> Commit: Ingo Molnar <mingo@xxxxxxxxxx>
> 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:
>
>
> On Sat, 04 Jun 2016 17:08:36 +0000 bugzilla-daemon@xxxxxxxxxxxxxxxxxxx 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: akpm@xxxxxxxxxxxxxxxxxxxx
>> Reporter: jp.pozzi@xxxxxxxxx
>> 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
>>
>> --
>> 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 majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href