Skip to content

hugetlb multi size, giant hugetlb support, etc

[email protected] linux-mm 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest21 patches 25 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/21hugetlb: factor out prep_new_huge_pagemm/hugetlb.c+11 -60 replies
2/21hugetlb: modular statearch/ia64/mm/hugetlbpage.c arch/powerpc/mm/hugetlbpage.c arch/s390/mm/hugetlbpage.c +16 more+352 -2141 reply
3/21hugetlb: multiple hstatesinclude/linux/hugetlb.h kernel/sysctl.c mm/hugetlb.c+142 -330 replies
4/21hugetlbfs: per mount hstatesfs/hugetlbfs/inode.c include/linux/hugetlb.h mm/hugetlb.c +1 more+64 -290 replies
5/21hugetlb: new sysfs interfaceDocumentation/ABI/testing/sysfs-kernel-hugepages include/linux/hugetlb.h mm/hugetlb.c+244 -660 replies
6/21hugetlb: abstract numa round robin selectionmm/hugetlb.c+22 -150 replies
7/21mm: introduce non panic alloc_bootmeminclude/linux/bootmem.h mm/bootmem.c+16 -00 replies
8/21mm: export prep_compound_page to mmmm/internal.h mm/page_alloc.c+3 -10 replies
9/21hugetlb: support larger than MAX_ORDERmm/hugetlb.c+81 -20 replies
10/21hugetlb: support boot allocate different sizesmm/hugetlb.c+30 -90 replies
11/21hugetlb: printk cleanupmm/hugetlb.c+16 -40 replies
12/21hugetlb: introduce pud_hugearch/ia64/mm/hugetlbpage.c arch/powerpc/mm/hugetlbpage.c arch/sh/mm/hugetlbpage.c +5 more+70 -50 replies
13/21x86: support GB hugepages on 64-bitarch/x86/mm/hugetlbpage.c+22 -110 replies
14/21x86: add hugepagesz option on 64-bitDocumentation/kernel-parameters.txt arch/x86/mm/hugetlbpage.c include/asm-x86/page.h+28 -215 replies
15/21hugetlb: override default huge page sizeDocumentation/kernel-parameters.txt mm/hugetlb.c+25 -70 replies
16/21hugetlb: allow arch overried hugepage allocationinclude/linux/hugetlb.h mm/hugetlb.c+13 -80 replies
17/21powerpc: function to allocate gigantic hugepagesarch/powerpc/mm/hugetlbpage.c+21 -00 replies
18/21powerpc: scan device tree for gigantic pagesarch/powerpc/mm/hash_utils_64.c arch/powerpc/mm/hugetlbpage.c include/asm-powerpc/mmu-hash64.h+61 -10 replies
19/21powerpc: define support for 16G hugepagesarch/powerpc/mm/hugetlbpage.c include/asm-powerpc/pgtable-64k.h+45 -190 replies
20/21fs: check for statfs overflowfs/compat.c fs/open.c+6 -50 replies
21/21powerpc: support multiple hugepage sizesDocumentation/kernel-parameters.txt arch/powerpc/mm/hash_utils_64.c arch/powerpc/mm/hugetlbpage.c +6 more+200 -1190 replies

Reviews trailers per patch

14 of 21 patches have a Reviewed-by or Acked-by of their own; the series has one for all of them.

PatchAdam LitkeNishanth AravamudanGreg Kroah-HartmanAndrew HastingsAndy Whitcroft
SeriesA-b
1/21A-b A-b
2/21A-b A-b A-b A-b
3/21A-b A-b
4/21A-b A-b
5/21A-b
6/21A-b A-b
7/21
8/21A-b
9/21A-b
10/21A-b A-b A-b
11/21A-b A-b
12/21
13/21
14/21
15/21
16/21A-b
17/21A-b
18/21A-b
19/21
20/21A-b
21/21

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes. Scroll the table sideways for all 5 reviewers.

Read the v1 thread

Cover letter [patch 00/21] hugetlb multi size, giant hugetlb support, etc

Hi,

Here is my submission to be merged in -mm. Given the amount of hunks this patchset has, and the recent flurry of hugetlb development work, I'd hope to get this merged up provided there aren't major issues (I would prefer to fix minor ones with incremental patches). It's just a lot of error prone work to track -mm when multiple concurrent development is happening.

Patch against latest mmotm.

What I have done for the user API issues with this release is to take the safe way out and just maintain the existing hugepages user interfaces unchanged. I've integrated Nish's sysfs API to control the other huge page sizes.

I had initially opted to drop the /proc/sys/vm/* parts of the changes, but I found that the libhugetlbfs suite continued to have failures, so I decided to revert the multi column /proc/meminfo changes too, for now.

I say for now, because it is very easy to subsequently agree on some extention to the API, but it is much harder to revert such an extention once it has been made. I also think the main thing at this point is to get the existing patchset merged. User API changes I really don't want to worry with at the moment... point is: the infrastructure changes are a lot of work to code, but not so hard to get right; the user API changes are easy to code but harder to get right.

New to this patchset: I have implemented a default_hugepagesz= boot option (defaulting to the arch's HPAGE_SIZE if unspecified), which can be used to specify the default hugepage size for all /proc/* files, SHM, and default hugetlbfs mount size. This is the best compromise I could find to keep back compatibility while allowing the possibility to try different sizes with legacy code.

One thing I worry about is whether the sysfs API is going to be foward compatible with NUMA allocation changes that might be in the pipe. This need not hold up a merge into -mm, but I'd like some reassurances that thought is put in before it goes upstream.

Lastly, embarassingly, I'm not the best source of information for the sysfs tunables, so incremental patches against Documentation/ABI would be welcome :P

Thanks,
Nick

Signature · 5 lines
--
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>

Read the cover letter in its thread