All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Mike Kravetz <mike.kravetz@oracle.com>,
	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>
Subject: Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations
Date: Thu, 12 Apr 2018 13:40:24 -0700	[thread overview]
Message-ID: <74b7c6e5-bce6-a70a-287a-af44765836c7@intel.com> (raw)
In-Reply-To: <770445b3-6caa-a87a-5de7-3157fc5280c2@intel.com>

Hi Mike,

On 2/15/2018 12:22 PM, Reinette Chatre wrote:
> On 2/12/2018 2:20 PM, Mike Kravetz wrote:
>> 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.
> 
> As discussed in another thread a new feature, Cache Pseudo-Locking,
> requires large contiguous regions. Until now I just exposed
> alloc_gigantic_page() to handle these allocations in my testing. I now
> moved to using find_alloc_contig_pages() as introduced here and all my
> tests passed. I do hope that an API supporting large contiguous regions
> become available.
> 
> Thank you very much for creating this.
> 
> Tested-by: Reinette Chatre <reinette.chatre@intel.com>

Do you still intend on submitting these changes for inclusion?

I would really like to use this work but unfortunately the original
patches submitted here do not apply anymore. I am encountering conflicts
with, for example:

commit d9cc948f6fa1c3384037f500e0acd35f03850d15
Author: Michal Hocko <mhocko@suse.com>
Date:   Wed Jan 31 16:20:44 2018 -0800

    mm, hugetlb: integrate giga hugetlb more naturally to the allocation
path

Thank you very much

Reinette

  reply	other threads:[~2018-04-12 20:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12 22:20 [RFC PATCH 0/3] Interface for higher order contiguous allocations Mike Kravetz
2018-02-12 22:20 ` Mike Kravetz
2018-02-12 22:20 ` [RFC PATCH 1/3] mm: make start_isolate_page_range() fail if already isolated Mike Kravetz
2018-02-12 22:20   ` Mike Kravetz
2018-02-13  9:46   ` Mike Rapoport
2018-02-13  9:46     ` Mike Rapoport
2018-02-16  0:40   ` Mike Kravetz
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-12 22:20   ` Mike Kravetz
2018-02-13  9:53   ` Mike Rapoport
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-12 22:20   ` Mike Kravetz
2018-02-15 20:22 ` [RFC PATCH 0/3] Interface for higher order contiguous allocations Reinette Chatre
2018-02-15 20:22   ` Reinette Chatre
2018-04-12 20:40   ` Reinette Chatre [this message]
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=74b7c6e5-bce6-a70a-287a-af44765836c7@intel.com \
    --to=reinette.chatre@intel.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=mike.kravetz@oracle.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.