| Message ID | 1442212051-15235-1-git-send-email-khandual@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
Anshuman Khandual <khandual@linux.vnet.ibm.com> writes: > When a 16GB huge page is requested on POWER platform through kernel command > line interface, it silently fails because of the lack of any gigantic pages > on the system which the platform should have communicated through 16GB memory > blocks in the device tree during boot time. For example > > [ 0.480940] HugeTLB registered 16 GB page size, pre-allocated 0 pages > [ 0.480945] HugeTLB registered 16 MB page size, pre-allocated 16 pages > > This adds a warning message during alloc_bootmem_huge_page request both on > book3e and book3s powerpc platforms. After this change > > [ 0.000000] Gigantic HugeTLB page not available > [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages > [ 0.473423] HugeTLB registered 16 MB page size, pre-allocated 16 pages That info is already part of the second line isn't it ? ie [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages pre-allocated 0 pages indicate we didn't allocate anything. So why do we need to add more details fo kernel output ? -aneesh
On 14.09.2015 [18:59:25 +0530], Aneesh Kumar K.V wrote: > Anshuman Khandual <khandual@linux.vnet.ibm.com> writes: > > > When a 16GB huge page is requested on POWER platform through kernel command > > line interface, it silently fails because of the lack of any gigantic pages > > on the system which the platform should have communicated through 16GB memory > > blocks in the device tree during boot time. For example > > > > [ 0.480940] HugeTLB registered 16 GB page size, pre-allocated 0 pages > > [ 0.480945] HugeTLB registered 16 MB page size, pre-allocated 16 pages > > > > This adds a warning message during alloc_bootmem_huge_page request both on > > book3e and book3s powerpc platforms. After this change > > > > [ 0.000000] Gigantic HugeTLB page not available > > [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages > > [ 0.473423] HugeTLB registered 16 MB page size, pre-allocated 16 pages > > > That info is already part of the second line isn't it ? ie > > [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages > > pre-allocated 0 pages indicate we didn't allocate anything. So why do we > need to add more details fo kernel output ? Agreed, the '0 pages' message indicates we failed to pre-allocate any pages. The 'pre-allocate' messages are specifically about the kernel command-line requests for hugepages. Not sure I understand the motivation for this? -Nish
On Mon, 2015-09-14 at 09:24 -0700, Nishanth Aravamudan wrote: > On 14.09.2015 [18:59:25 +0530], Aneesh Kumar K.V wrote: > > Anshuman Khandual <khandual@linux.vnet.ibm.com> writes: > > > > > When a 16GB huge page is requested on POWER platform through kernel command > > > line interface, it silently fails because of the lack of any gigantic pages > > > on the system which the platform should have communicated through 16GB memory > > > blocks in the device tree during boot time. For example > > > > > > [ 0.480940] HugeTLB registered 16 GB page size, pre-allocated 0 pages > > > [ 0.480945] HugeTLB registered 16 MB page size, pre-allocated 16 pages > > > > > > This adds a warning message during alloc_bootmem_huge_page request both on > > > book3e and book3s powerpc platforms. After this change > > > > > > [ 0.000000] Gigantic HugeTLB page not available > > > [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages > > > [ 0.473423] HugeTLB registered 16 MB page size, pre-allocated 16 pages > > > > That info is already part of the second line isn't it ? ie > > > > [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages > > > > pre-allocated 0 pages indicate we didn't allocate anything. So why do we > > need to add more details fo kernel output ? > > Agreed, the '0 pages' message indicates we failed to pre-allocate any > pages. The 'pre-allocate' messages are specifically about the kernel > command-line requests for hugepages. Yeah, that's sufficient. We don't need more boot-time log spam. All the info you need should be in /sys/kernel/mm anyway. If it's not, then that is something we should fix. cheers
On 09/14/2015 09:54 PM, Nishanth Aravamudan wrote: > On 14.09.2015 [18:59:25 +0530], Aneesh Kumar K.V wrote: >> > Anshuman Khandual <khandual@linux.vnet.ibm.com> writes: >> > >>> > > When a 16GB huge page is requested on POWER platform through kernel command >>> > > line interface, it silently fails because of the lack of any gigantic pages >>> > > on the system which the platform should have communicated through 16GB memory >>> > > blocks in the device tree during boot time. For example >>> > > >>> > > [ 0.480940] HugeTLB registered 16 GB page size, pre-allocated 0 pages >>> > > [ 0.480945] HugeTLB registered 16 MB page size, pre-allocated 16 pages >>> > > >>> > > This adds a warning message during alloc_bootmem_huge_page request both on >>> > > book3e and book3s powerpc platforms. After this change >>> > > >>> > > [ 0.000000] Gigantic HugeTLB page not available >>> > > [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages >>> > > [ 0.473423] HugeTLB registered 16 MB page size, pre-allocated 16 pages >> > >> > >> > That info is already part of the second line isn't it ? ie >> > >> > [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages >> > >> > pre-allocated 0 pages indicate we didn't allocate anything. So why do we >> > need to add more details fo kernel output ? > Agreed, the '0 pages' message indicates we failed to pre-allocate any > pages. The 'pre-allocate' messages are specifically about the kernel > command-line requests for hugepages. > > Not sure I understand the motivation for this? The motivation was just to add a cause to the failure of allocation of requested 16G huge pages. I think "pre-allocated 0 pages" does not hint about the cause of the failure.
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index 06c1452..54f3e42 100644 --- a/arch/powerpc/mm/hugetlbpage.c +++ b/arch/powerpc/mm/hugetlbpage.c @@ -307,8 +307,10 @@ int alloc_bootmem_huge_page(struct hstate *hstate) int idx = shift_to_mmu_psize(huge_page_shift(hstate)); int nr_gpages = gpage_freearray[idx].nr_gpages; - if (nr_gpages == 0) + if (nr_gpages == 0) { + printk(KERN_WARNING "Gigantic HugeTLB page not available\n"); return 0; + } #ifdef CONFIG_HIGHMEM /* @@ -429,8 +431,10 @@ void add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages) int alloc_bootmem_huge_page(struct hstate *hstate) { struct huge_bootmem_page *m; - if (nr_gpages == 0) + if (nr_gpages == 0) { + printk(KERN_WARNING "Gigantic HugeTLB page not available\n"); return 0; + } m = phys_to_virt(gpage_freearray[--nr_gpages]); gpage_freearray[nr_gpages] = 0; list_add(&m->list, &huge_boot_pages);
When a 16GB huge page is requested on POWER platform through kernel command line interface, it silently fails because of the lack of any gigantic pages on the system which the platform should have communicated through 16GB memory blocks in the device tree during boot time. For example [ 0.480940] HugeTLB registered 16 GB page size, pre-allocated 0 pages [ 0.480945] HugeTLB registered 16 MB page size, pre-allocated 16 pages This adds a warning message during alloc_bootmem_huge_page request both on book3e and book3s powerpc platforms. After this change [ 0.000000] Gigantic HugeTLB page not available [ 0.473417] HugeTLB registered 16 GB page size, pre-allocated 0 pages [ 0.473423] HugeTLB registered 16 MB page size, pre-allocated 16 pages Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com> --- arch/powerpc/mm/hugetlbpage.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)