• Mike Kravetz's avatar
    hugetlbfs: clean up command line processing · 282f4214
    Mike Kravetz authored
    With all hugetlb page processing done in a single file clean up code.
    
    - Make code match desired semantics
      - Update documentation with semantics
    - Make all warnings and errors messages start with 'HugeTLB:'.
    - Consistently name command line parsing routines.
    - Warn if !hugepages_supported() and command line parameters have
      been specified.
    - Add comments to code
      - Describe some of the subtle interactions
      - Describe semantics of command line arguments
    
    This patch also fixes issues with implicitly setting the number of
    gigantic huge pages to preallocate.  Previously on X86 command line,
    
            hugepages=2 default_hugepagesz=1G
    
    would result in zero 1G pages being preallocated and,
    
            # grep HugePages_Total /proc/meminfo
            HugePages_Total:       0
            # sysctl -a | grep nr_hugepages
            vm.nr_hugepages = 2
            vm.nr_hugepages_mempolicy = 2
            # cat /proc/sys/vm/nr_hugepages
            2
    
    After this patch 2 gigantic pages will be preallocated and all the proc,
    sysfs, sysctl and meminfo files will accurately reflect this.
    
    To address the issue with gigantic pages, a small change in behavior was
    made to command line processing.  Previously the command line,
    
            hugepages=128 default_hugepagesz=2M hugepagesz=2M hugepages=256
    
    would result in the allocation of 256 2M huge pages.  The value 128 would
    be ignored without any warning.  After this patch, 128 2M pages will be
    allocated and a warning message will be displayed indicating the value of
    256 is ignored.  This change in behavior is required because allocation of
    implicitly specified gigantic pages must be done when the
    default_hugepagesz= is encountered for gigantic pages.  Previously the
    code waited until later in the boot process (hugetlb_init), to allocate
    pages of default size.  However the bootmem allocator required for
    gigantic allocations is not available at this time.
    Signed-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Tested-by: default avatarSandipan Das <sandipan@linux.ibm.com>
    Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>	[s390]
    Acked-by: default avatarWill Deacon <will@kernel.org>
    Cc: Albert Ou <aou@eecs.berkeley.edu>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
    Cc: Christophe Leroy <christophe.leroy@c-s.fr>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Longpeng <longpeng2@huawei.com>
    Cc: Mina Almasry <almasrymina@google.com>
    Cc: Nitesh Narayan Lal <nitesh@redhat.com>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Anders Roxell <anders.roxell@linaro.org>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Link: http://lkml.kernel.org/r/20200417185049.275845-5-mike.kravetz@oracle.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    282f4214
hugetlb.c 157 KB