Hi Alistair/Jeremy,
I am working on a bug related to 1M hugepage size being registered on
Linux (Power 8 Baremetal - Garrison).
I was checking dmesg and it seems that 1M page size is coming from
firmware to Linux.
[ 0.000000] base_shift=20: shift=20, sllp=0x0130, avpnm=0x00000000,
tlbiel=0, penc=2
[ 1.528867] HugeTLB registered 1 MB page size, pre-allocated 0 pages
Should Linux support this page size? As afar as I know, this was an
unsupported page size in the past isn't it? If this should be supported
now, is there any specific reason for that?
Thanks,
Victor Aoqui
Software Engineer: Linux Kernel Backports
Linux Technology Center
IBM Systems
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-06-21 10:33:08
victora [off-list ref] writes:
Hi Alistair/Jeremy,
I am working on a bug related to 1M hugepage size being registered on
Linux (Power 8 Baremetal - Garrison).
Wasn't that caused by a firmware bug?
I was checking dmesg and it seems that 1M page size is coming from
firmware to Linux.
[ 0.000000] base_shift=20: shift=20, sllp=0x0130, avpnm=0x00000000,
tlbiel=0, penc=2
[ 1.528867] HugeTLB registered 1 MB page size, pre-allocated 0 pages
Should Linux support this page size?
Does it work? :)
The user manual says it's a supported size, but I thought it didn't work
(in hardware) for some reason.
cheers
From: Mauricio Faria de Oliveira <hidden> Date: 2017-06-21 15:32:24
On 06/21/2017 07:33 AM, Michael Ellerman wrote:
quoted
I am working on a bug related to 1M hugepage size being registered on
Linux (Power 8 Baremetal - Garrison).
Wasn't that caused by a firmware bug?
Ben/Stewart, does that ring a bell, something new, intended or not? :- )
Thanks,
quoted
I was checking dmesg and it seems that 1M page size is coming from
firmware to Linux.
[ 0.000000] base_shift=20: shift=20, sllp=0x0130, avpnm=0x00000000,
tlbiel=0, penc=2
[ 1.528867] HugeTLB registered 1 MB page size, pre-allocated 0 pages
Should Linux support this page size?
Does it work?:)
The user manual says it's a supported size, but I thought it didn't work
(in hardware) for some reason.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-06-22 03:59:41
Hi Victor,
Someone refreshed my memory on this, coffee was involved ...
victora [off-list ref] writes:
Hi Alistair/Jeremy,
I am working on a bug related to 1M hugepage size being registered on
Linux (Power 8 Baremetal - Garrison).
On those machines the property in the device tree comes straight from
hostboot, and it includes 1M:
# lsprop ibm,segment-page-sizes
ibm,segment-page-sizes
0000000c 00000000 00000003 0000000c
baseshift slbenc lpnum shift
00000000 00000010 00000007 00000018
penc shift penc shift
00000038 00000010 00000110 00000002
penc baseshift slbenc lpnum
00000010 00000001 00000018 00000008
shift penc shift penc
00000014 00000130 00000001 00000014 <--- 1MB = 2^0x14
baseshift slbenc lpnum shift
00000002 00000018 00000100 00000001
penc baseshift slbenc lpnum
00000018 00000000 00000022 00000120
shift penc baseshift slbenc
00000001 00000022 00000003
lpnum shift penc
I was checking dmesg and it seems that 1M page size is coming from
firmware to Linux.
[ 0.000000] base_shift=20: shift=20, sllp=0x0130, avpnm=0x00000000, tlbiel=0, penc=2
[ 1.528867] HugeTLB registered 1 MB page size, pre-allocated 0 pages
Which is why you see that message.
Should Linux support this page size? As afar as I know, this was an
unsupported page size in the past isn't it? If this should be supported
now, is there any specific reason for that?
It's unsupported in Linux because it doesn't match the page table
geometry.
We merged a patch from Aneesh to filter it out in 4.12-rc1:
a525108cf1cc ("powerpc/mm/hugetlb: Filter out hugepage size not supported by page table layout")
I guess we should probably send that patch to stable et. al.
cheers
From: Benjamin Herrenschmidt <hidden> Date: 2017-06-22 08:09:57
On Thu, 2017-06-22 at 13:59 +1000, Michael Ellerman wrote:
It's unsupported in Linux because it doesn't match the page table
geometry.
We merged a patch from Aneesh to filter it out in 4.12-rc1:
a525108cf1cc ("powerpc/mm/hugetlb: Filter out hugepage size not supported by page table layout")
I guess we should probably send that patch to stable et. al.
It's also not supported in HW afaik, why is it there ?
Cheers,
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2017-06-22 08:21:52
On Wed, 2017-06-21 at 20:33 +1000, Michael Ellerman wrote:
victora [off-list ref] writes:
quoted
Hi Alistair/Jeremy,
I am working on a bug related to 1M hugepage size being registered on
Linux (Power 8 Baremetal - Garrison).
Wasn't that caused by a firmware bug?
quoted
I was checking dmesg and it seems that 1M page size is coming from
firmware to Linux.
[ 0.000000] base_shift=20: shift=20, sllp=0x0130, avpnm=0x00000000,
tlbiel=0, penc=2
[ 1.528867] HugeTLB registered 1 MB page size, pre-allocated 0 pages
Should Linux support this page size?
Does it work? :)
The user manual says it's a supported size, but I thought it didn't work
(in hardware) for some reason.
Right, I thought there was some config bit to switch between 1M and 16M
and that had never been fully verified ? I don't remember the details.
On Wed, 2017-06-21 at 12:32 -0300, Mauricio Faria de Oliveira wrote:
On 06/21/2017 07:33 AM, Michael Ellerman wrote:
quoted
quoted
I am working on a bug related to 1M hugepage size being registered on
Linux (Power 8 Baremetal - Garrison).
Wasn't that caused by a firmware bug?
Ben/Stewart, does that ring a bell, something new, intended or not? :- )
Aneesh changed the code to support just 16M and 16G hugepages for hash even
if the firmware exported that size. What is your end goal to support those
pages or to prevent them from being used?
Balbir Singh.
From: Michal Suchánek <hidden> Date: 2017-06-22 11:03:21
On Tue, 20 Jun 2017 10:47:47 -0300
victora [off-list ref] wrote:
Hi Alistair/Jeremy,
I am working on a bug related to 1M hugepage size being registered on
Linux (Power 8 Baremetal - Garrison).
I was checking dmesg and it seems that 1M page size is coming from
firmware to Linux.
[ 0.000000] base_shift=20: shift=20, sllp=0x0130,
avpnm=0x00000000, tlbiel=0, penc=2
[ 1.528867] HugeTLB registered 1 MB page size, pre-allocated 0
pages
Should Linux support this page size? As afar as I know, this was an
unsupported page size in the past isn't it? If this should be
supported now, is there any specific reason for that?
Hello,
a525108cf1cc powerpc/mm/hugetlb: Filter out hugepage size not supported
by page table layout
Should reject unsupported huge page sizes, right?
Thanks
Michal
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-06-22 11:17:56
Benjamin Herrenschmidt [off-list ref] writes:
On Thu, 2017-06-22 at 13:59 +1000, Michael Ellerman wrote:
quoted
It's unsupported in Linux because it doesn't match the page table
geometry.
=20
We merged a patch from Aneesh to filter it out in 4.12-rc1:
=20
=C2=A0 a525108cf1cc ("powerpc/mm/hugetlb: Filter out hugepage size not s=
upported by page table layout")
quoted
=20
I guess we should probably send that patch to stable et. al.
It's also not supported in HW afaik, why is it there ?
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-06-23 05:26:25
Michal Such=C3=A1nek [off-list ref] writes:
On Tue, 20 Jun 2017 10:47:47 -0300
victora [off-list ref] wrote:
quoted
Hi Alistair/Jeremy,
=20
I am working on a bug related to 1M hugepage size being registered on=20
Linux (Power 8 Baremetal - Garrison).
=20
I was checking dmesg and it seems that 1M page size is coming from=20
firmware to Linux.
=20
[ 0.000000] base_shift=3D20: shift=3D20, sllp=3D0x0130,
avpnm=3D0x00000000, tlbiel=3D0, penc=3D2
[ 1.528867] HugeTLB registered 1 MB page size, pre-allocated 0
pages
=20
Should Linux support this page size? As afar as I know, this was an=20
unsupported page size in the past isn't it? If this should be
supported now, is there any specific reason for that?
Hello,
a525108cf1cc powerpc/mm/hugetlb: Filter out hugepage size not supported
by page table layout
Should reject unsupported huge page sizes, right?
Hi Victor,
Someone refreshed my memory on this, coffee was involved ...
victora [off-list ref] writes:
quoted
Hi Alistair/Jeremy,
I am working on a bug related to 1M hugepage size being registered on
Linux (Power 8 Baremetal - Garrison).
On those machines the property in the device tree comes straight from
hostboot, and it includes 1M:
# lsprop ibm,segment-page-sizes
ibm,segment-page-sizes
0000000c 00000000 00000003 0000000c
baseshift slbenc lpnum shift
00000000 00000010 00000007 00000018
penc shift penc shift
00000038 00000010 00000110 00000002
penc baseshift slbenc lpnum
00000010 00000001 00000018 00000008
shift penc shift penc
00000014 00000130 00000001 00000014 <--- 1MB = 2^0x14
baseshift slbenc lpnum shift
00000002 00000018 00000100 00000001
penc baseshift slbenc lpnum
00000018 00000000 00000022 00000120
shift penc baseshift slbenc
00000001 00000022 00000003
lpnum shift penc
quoted
I was checking dmesg and it seems that 1M page size is coming from
firmware to Linux.
[ 0.000000] base_shift=20: shift=20, sllp=0x0130, avpnm=0x00000000,
tlbiel=0, penc=2
[ 1.528867] HugeTLB registered 1 MB page size, pre-allocated 0
pages
Which is why you see that message.
quoted
Should Linux support this page size? As afar as I know, this was an
unsupported page size in the past isn't it? If this should be
supported
now, is there any specific reason for that?
It's unsupported in Linux because it doesn't match the page table
geometry.
We merged a patch from Aneesh to filter it out in 4.12-rc1:
a525108cf1cc ("powerpc/mm/hugetlb: Filter out hugepage size not
supported by page table layout")
I guess we should probably send that patch to stable et. al.
cheers
Hi Michael,
Sorry for the delay. Thanks for merging that patch.
Was that patch also sent to stable et. al.?
Thanks
Victor
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-06-26 03:14:41
victora [off-list ref] writes:
Em 2017-06-22 00:59, Michael Ellerman escreveu:
quoted
We merged a patch from Aneesh to filter it out in 4.12-rc1:
a525108cf1cc ("powerpc/mm/hugetlb: Filter out hugepage size not
supported by page table layout")
I guess we should probably send that patch to stable et. al.
^
:)
Sorry for the delay. Thanks for merging that patch.
Was that patch also sent to stable et. al.?