Received: by 10.223.185.116 with SMTP id b49csp2698317wrg; Mon, 12 Feb 2018 14:23:26 -0800 (PST) X-Google-Smtp-Source: AH8x224Ssa4Qc3GstI/x7hLKsy/7XrlRZNgKkkhk5o7yrTSipiJf2adcEQWRPmQAO0PTj75Mu20P X-Received: by 10.101.69.141 with SMTP id o13mr10069650pgq.394.1518474206584; Mon, 12 Feb 2018 14:23:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518474206; cv=none; d=google.com; s=arc-20160816; b=hvzRF5zInTdl7unYg5KgmzoitKmfRQbQWocXxJAHsdWD9WySTWZRB/mKDcSiv/ENpo XSGzpvpAiRAvP6SeHN2F1ZQ6uGiE4lTFYEel85IhZ7PowlHh+qOfBwSuqypSx13WcV4c cZkwR1blDM/xmE6c9lg8lBWwbrjcUkbXWmTlkYYDDUBvy+wBHWlQuDSBaAB7jHy35Skx m7ITOScdhpb0FARLtSvKv5CvNMraUdDlbJx+7iUKH10vVyPIy/QyzUR673uxBs/wsKxO ZUqPUCXYtcAjSK5EloqsdIm2gqfThNnBK8rGVE/LJHhsA36SAbPAA6pi+cTIUSDCj80j IjiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=KdePWuDHygjt11XOvRPoF25Jvhg5t/cizCv/xnxVar0=; b=1Huw1cqRsCsj7L6Vad9oTCN+eFHqNhMmT895L9ZRZ9TXIOi4Vea/P9cghOf4PcayLs CtcCwMYqRHdh2DClLJTk2bAquwnAWLGEckmfGKso2Vr94i9oJlS5jvXL0RNx+pdADE80 PPteA0NbqEOLc6vI9zbTpMKP/eXwAaTt7Cfiqh4JniEzVIXf1KK6ibNsgCcDVc7+ujey VadLhf4nsFDzPMffXgl4x2Oa59otfn3NuO/kP+9gqKXGA3JU0DHSyUKcfaC1mt3J7HR3 pLCAr3Fg0/jZSI+HDtLy5XayRYWNJqK65zhk40bEVL7mOmCqfvlhSFUOCfWjR3R/bbMV zKvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=TRywjQxD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y14si5616606pgs.701.2018.02.12.14.23.12; Mon, 12 Feb 2018 14:23:26 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=TRywjQxD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932704AbeBLWVt (ORCPT + 99 others); Mon, 12 Feb 2018 17:21:49 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:37972 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932628AbeBLWVq (ORCPT ); Mon, 12 Feb 2018 17:21:46 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w1CMHPfp178281; Mon, 12 Feb 2018 22:21:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=KdePWuDHygjt11XOvRPoF25Jvhg5t/cizCv/xnxVar0=; b=TRywjQxD78qwTv9Orj+HzugjqaxafZ9qZhiDHzC22i3HJuTxvG/IStgztJnDJ+EB8Bi+ 82aVtC+13WBciDZbdJ40QdouSLLqr9YGmBqQlvwU6vP1W+rNCKegkZhlksL7qDXHfBii +k11/At+9TwE5/NVhtZCC54M8dn+KzT9i7A1o/hk7dae/0yzHgnn4ZhQumlvpmdk3/eK ACSdY3ajmL3ykcgUdD0aK+HchuGB3/05+NPaDMkXAWJtlXWBldHFRfn/pAySDsC7A8Ic XBTk0tGuVS+YJC1pe5H5fAlfCDH4FHiRhmwZUxfTpd4biYaS4SHV6B6b6//ulz1/t7ad lw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2g3jtdr9bx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Feb 2018 22:21:20 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w1CMLIxd032544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Feb 2018 22:21:19 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w1CMLFZd004125; Mon, 12 Feb 2018 22:21:16 GMT Received: from monkey.oracle.com (/98.246.252.205) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Feb 2018 14:21:15 -0800 From: Mike Kravetz To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Michal Hocko , Christopher Lameter , Guy Shattah , Anshuman Khandual , Michal Nazarewicz , Vlastimil Babka , David Nellans , Laura Abbott , Pavel Machek , Dave Hansen , Mike Kravetz Subject: [RFC PATCH 0/3] Interface for higher order contiguous allocations Date: Mon, 12 Feb 2018 14:20:53 -0800 Message-Id: <20180212222056.9735-1-mike.kravetz@oracle.com> X-Mailer: git-send-email 2.13.6 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8803 signatures=668668 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=904 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802120282 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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