From: Mike Kravetz <mike.kravetz@oracle.com> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Hillf Danton <hdanton@sina.com>, Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@kernel.org>, Mel Gorman <mgorman@suse.de>, Johannes Weiner <hannes@cmpxchg.org>, Andrea Arcangeli <aarcange@redhat.com>, David Rientjes <rientjes@google.com>, Andrew Morton <akpm@linux-foundation.org>, Mike Kravetz <mike.kravetz@oracle.com> Subject: [PATCH 0/3] address hugetlb page allocation stalls Date: Fri, 2 Aug 2019 15:39:27 -0700 [thread overview] Message-ID: <20190802223930.30971-1-mike.kravetz@oracle.com> (raw) Allocation of hugetlb pages via sysctl or procfs can stall for minutes or hours. A simple example on a two node system with 8GB of memory is as follows: echo 4096 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages echo 4096 > /proc/sys/vm/nr_hugepages Obviously, both allocation attempts will fall short of their 8GB goal. However, one or both of these commands may stall and not be interruptible. The issues were initially discussed in mail thread [1] and RFC code at [2]. This series addresses the issues causing the stalls. There are two distinct fixes, and an optimization. The reclaim patch by Hillf and compaction patch by Vlasitmil address corner cases in their respective areas. hugetlb page allocation could stall due to either of these issues. The hugetlb patch by Mike is an optimization suggested during the debug and development process. [1] http://lkml.kernel.org/r/d38a095e-dc39-7e82-bb76-2c9247929f07@oracle.com [2] http://lkml.kernel.org/r/20190724175014.9935-1-mike.kravetz@oracle.com Hillf Danton (1): mm, reclaim: make should_continue_reclaim perform dryrun detection Mike Kravetz (1): hugetlbfs: don't retry when pool page allocations start to fail Vlastimil Babka (1): mm, compaction: raise compaction priority after it withdrawns include/linux/compaction.h | 22 +++++++--- mm/hugetlb.c | 86 +++++++++++++++++++++++++++++++++----- mm/page_alloc.c | 16 +++++-- mm/vmscan.c | 28 +++++++------ 4 files changed, 120 insertions(+), 32 deletions(-) -- 2.20.1
next reply other threads:[~2019-08-02 22:42 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-02 22:39 Mike Kravetz [this message] 2019-08-02 22:39 ` [PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection Mike Kravetz 2019-08-05 8:42 ` Vlastimil Babka 2019-08-05 10:57 ` Vlastimil Babka 2019-08-05 16:58 ` Mike Kravetz 2019-08-05 18:34 ` Vlastimil Babka 2019-08-05 16:54 ` Mike Kravetz 2019-08-02 22:39 ` [PATCH 2/3] mm, compaction: raise compaction priority after it withdrawns Mike Kravetz 2019-08-05 9:14 ` Vlastimil Babka 2019-08-02 22:39 ` [PATCH 3/3] hugetlbfs: don't retry when pool page allocations start to fail Mike Kravetz 2019-08-05 9:28 ` Vlastimil Babka 2019-08-05 17:12 ` Mike Kravetz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190802223930.30971-1-mike.kravetz@oracle.com \ --to=mike.kravetz@oracle.com \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=hdanton@sina.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=mhocko@kernel.org \ --cc=rientjes@google.com \ --cc=vbabka@suse.cz \ --subject='Re: [PATCH 0/3] address hugetlb page allocation stalls' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).