Received: by 10.192.165.148 with SMTP id m20csp134497imm; Thu, 3 May 2018 16:31:32 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoKl3GbxhZ6k4IK8jL/pwxbW4rJMU0oe4dti+Ip2afgua3yLWR/6aOoPO1muWvTCuJFfX4C X-Received: by 2002:a65:4542:: with SMTP id x2-v6mr21088107pgr.24.1525390292664; Thu, 03 May 2018 16:31:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525390292; cv=none; d=google.com; s=arc-20160816; b=pV0wEsed8/Go1pt3gM0GpVfKi4KNZmDbVyMCkvzxSB+oT1bOTFYxuIh7vt+PqdVOt7 S7vKTOnhb1W6cWRIhBgHU++3zxgP+7UDVqnIMNpRWV+CBfIPYD9Jn78kZcqTZAfIE5gk dGnLyClDqZCQ2gAr1U6wCyyTsuAWSGZOupCp5wjbPVr/GGCorqtmKezEe7Um658gXzSa JK9pL72hJMUKIrUWixGNfVUQH8sPchfXxqgHl5NgAdtUEm3wNCLmSWSWcm9cxZWfi3gv y/0QN+q4SXDotMLg+NOj0cMH/5e1aA9PiR9OeCLINjSKbCC7HicqYwi8RcA15Sv+vv9/ u9mA== 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=d+QIAl5IBy6A59ONQ0X7R/KjyMfJ0I1rJGTnFWswUkA=; b=M4MID8eC2rAD0raUTb5BFMeTQhF6eOqWSrqgTY3Rl39YbeiGm2m1Du0lVZCDaWigFK zrbJ7T44e69t1GHvjws17stWQ3pwpYjsedUdI9EZ/8c+PhQPu9Y9MZzvDI80RVQ1U0Av 0lyacJ1/NH3eDGk3m5TiKileHn/kdfuXS4TredfrpNpXtC1EUUeT7bXFofSVno96ARWe qOcAr4LzB5dC1N/M1s18jBw3E4+j+7OaGj1qyqEgt7LjRlAXU5uA1Breo0JBS31KOdrI ip5Zdw9+li3OC3u3zJ72tSvjJ9K+xDhptNDJ4ymBbYiMch8HADGCcHt4mZ2R5uZl6dFH xlCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=hC8LXvbD; 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 t5-v6si3820397ply.598.2018.05.03.16.31.18; Thu, 03 May 2018 16:31:32 -0700 (PDT) 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=hC8LXvbD; 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 S1751417AbeECXah (ORCPT + 99 others); Thu, 3 May 2018 19:30:37 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:36996 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751011AbeECXa2 (ORCPT ); Thu, 3 May 2018 19:30:28 -0400 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 w43NLCJ8050958; Thu, 3 May 2018 23:29:48 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=d+QIAl5IBy6A59ONQ0X7R/KjyMfJ0I1rJGTnFWswUkA=; b=hC8LXvbDhdaZhxMzMPCpH1yhzDiRmvD02nNKosf99OjbWKuf0FHFzVPizBy3/11R+prM QkXcMhSTp15PgAvxpp97jVu3BzCtLySNj7Pc/tALx2RA6F6eNASZEJosD+cLoRRnW13c YHCNLhpiAMmt+O9J8hnzMG+QqYH/xMj5bM3/8GFlFIMOsXYfyHHW47LiqINcfih7eYtZ 3w8VhxQYZOFBcMwzWucx+81Z5J2tXZUeK3tFzbbc2MNyRKxlCZICezXX8fwh7ik6jKIm NhpGD7wSoGo5ZgiHUR/9uTs+gE9K0T1i4Z80HrvI/0mmt//jztM6YKCsS5Rve55xsuQr Jg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2hmhmfuvtb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 May 2018 23:29:47 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w43NTjhZ022902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 May 2018 23:29:46 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w43NTh14020148; Thu, 3 May 2018 23:29:43 GMT Received: from monkey.oracle.com (/50.38.38.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2018 16:29:43 -0700 From: Mike Kravetz To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Cc: Reinette Chatre , Michal Hocko , Christopher Lameter , Guy Shattah , Anshuman Khandual , Michal Nazarewicz , Vlastimil Babka , David Nellans , Laura Abbott , Pavel Machek , Dave Hansen , Andrew Morton , Mike Kravetz Subject: [PATCH v2 0/4] Interface for higher order contiguous allocations Date: Thu, 3 May 2018 16:29:31 -0700 Message-Id: <20180503232935.22539-1-mike.kravetz@oracle.com> X-Mailer: git-send-email 2.13.6 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8882 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030204 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org A respin of of the series to address these issues: - fix issues found by kbuild - find_alloc_contig_pages() should take nr_pages as argument instead of page order (Vlastimil and Michal). - Cleaned up migratetype handling (Vlastimil and Michal). - Use pfn_to_online_page instead of pfn_to_page as suggested by Michal. Also added comment about minimal number of conditions checked in contig_pfn_range_valid(). - When scanning pfns in zone, take pgdat_resize_lock() instead of zone->lock (Michal) Also, - Separate patch to change type of free_contig_range(nr_pages) to an unsigned long so that it is consistent with other uses of nr_pages. - Separate patch to optionally validate migratetype during pageblock isolation. - Make find_alloc_contig_pages() work for smaller size allocation by simply calling __alloc_pages_nodemask(). Vlastimil and Michal brought up the issue of allocation alignment. The routine will currently align to 'nr_pages' (which is the requested size argument). It does this by examining and trying to allocate the first nr_pages aligned/nr_pages sized range. If this fails, it moves on to the next nr_pages aligned/nr_pages sized range until success or all potential ranges are exhausted. If we allow an alignment to be specified, we will need to potentially check all alignment aligned/nr_pages sized ranges. In the worst case where alignment = PAGE_SIZE, this could result in huge increase in the number of ranges to check. To help cut down on the number of ranges to check, we could identify the first page that causes a range allocation failure and start the next range at the next aligned boundary. I tried this, and we still end up with a huge number of ranges and wasted CPU cycles. This series did not add an alignment option. Allocations are aligned to nr_pages as described above. If someone can thing of a good way to support an alignment argument, I am open to implementing/adding it. As described before, 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 long nr_pages, gfp_t gfp, int nid, nodemask_t *nodemask) This interface is essentially the same functionality provided by the hugetlb specific routine alloc_gigantic_page(). After creating the interface, change alloc_gigantic_page() to call find_alloc_contig_pages() and delete all the supporting code in hugetlb.c. A new use case for allocating contiguous memory has been identified in Intel(R) Resource Director Technology Cache Pseudo-Locking. Mike Kravetz (4): mm: change type of free_contig_range(nr_pages) to unsigned long mm: check for proper migrate type during isolation mm: add find_alloc_contig_pages() interface mm/hugetlb: use find_alloc_contig_pages() to allocate gigantic pages include/linux/gfp.h | 14 +++- include/linux/page-isolation.h | 8 +-- mm/cma.c | 2 +- mm/hugetlb.c | 87 ++-------------------- mm/memory_hotplug.c | 2 +- mm/page_alloc.c | 159 +++++++++++++++++++++++++++++++++++++---- mm/page_isolation.c | 40 ++++++++--- 7 files changed, 200 insertions(+), 112 deletions(-) -- 2.13.6