linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Michal Hocko <mhocko@kernel.org>,
	Christopher Lameter <cl@linux.com>,
	Guy Shattah <sguy@mellanox.com>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	Michal Nazarewicz <mina86@mina86.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	David Nellans <dnellans@nvidia.com>,
	Laura Abbott <labbott@redhat.com>, Pavel Machek <pavel@ucw.cz>,
	Dave Hansen <dave.hansen@intel.com>,
	Mike Kravetz <mike.kravetz@oracle.com>
Subject: [RFC PATCH 0/3] Interface for higher order contiguous allocations
Date: Mon, 12 Feb 2018 14:20:53 -0800	[thread overview]
Message-ID: <20180212222056.9735-1-mike.kravetz@oracle.com> (raw)

These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at:
http://lkml.kernel.org/r/21f1ec96-2822-1189-1c95-79a2bb491571@oracle.com

One suggestion in that thread was to create a friendlier interface that
could be used by drivers and others outside core mm code to allocate a
contiguous set of pages.  The alloc_contig_range() interface is used for
this purpose today by CMA and gigantic page allocation.  However, this is
not a general purpose interface.  So, wrap alloc_contig_range() in the
more general interface:

struct page *find_alloc_contig_pages(unsigned int order, gfp_t gfp, int nid,
					nodemask_t *nodemask)

No underlying changes are made to increase the likelihood that a contiguous
set of pages can be found and allocated.  Therefore, any user of this
interface must deal with failure.  The hope is that this interface will be
able to satisfy some use cases today.

If the "rate of failure" is too high to be useful, then more work can be put
into methods to help increase the rate of successful allocations.  Such a
proposal was recently sent by Christoph Lameter "[RFC] Protect larger order
pages from breaking up":
http://lkml.kernel.org/r/alpine.DEB.2.20.1802091311090.3059@nuc-kabylake

find_alloc_contig_pages() uses the same logic that exists today for scanning
zones to look for contiguous ranges suitable for gigantic pages.  The last
patch in the series changes gigantic page allocation to use the new interface.

Mike Kravetz (3):
  mm: make start_isolate_page_range() fail if already isolated
  mm: add find_alloc_contig_pages() interface
  mm/hugetlb: use find_alloc_contig_pages() to allocate gigantic pages

 include/linux/gfp.h | 12 +++++++
 mm/hugetlb.c        | 88 ++++--------------------------------------------
 mm/page_alloc.c     | 97 +++++++++++++++++++++++++++++++++++++++++++++++++----
 mm/page_isolation.c | 10 +++++-
 4 files changed, 118 insertions(+), 89 deletions(-)

-- 
2.13.6

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2018-02-12 22:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12 22:20 Mike Kravetz [this message]
2018-02-12 22:20 ` [RFC PATCH 1/3] mm: make start_isolate_page_range() fail if already isolated Mike Kravetz
2018-02-13  9:46   ` Mike Rapoport
2018-02-16  0:40   ` Mike Kravetz
2018-02-12 22:20 ` [RFC PATCH 2/3] mm: add find_alloc_contig_pages() interface Mike Kravetz
2018-02-13  9:53   ` Mike Rapoport
2018-02-12 22:20 ` [RFC PATCH 3/3] mm/hugetlb: use find_alloc_contig_pages() to allocate gigantic pages Mike Kravetz
2018-02-15 20:22 ` [RFC PATCH 0/3] Interface for higher order contiguous allocations Reinette Chatre
2018-04-12 20:40   ` Reinette Chatre
2018-04-12 20:58     ` Mike Kravetz
2018-04-16 13:14       ` Michal Hocko

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=20180212222056.9735-1-mike.kravetz@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=cl@linux.com \
    --cc=dave.hansen@intel.com \
    --cc=dnellans@nvidia.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mina86@mina86.com \
    --cc=pavel@ucw.cz \
    --cc=sguy@mellanox.com \
    --cc=vbabka@suse.cz \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).