Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp336284imu; Tue, 15 Jan 2019 23:10:27 -0800 (PST) X-Google-Smtp-Source: ALg8bN6CzzCaLBHujkFq4cYXLo+sllNs+6vyYQBGGOEl8mrcmIrUsEZqqqZB035CMzrEYH6K4iNA X-Received: by 2002:a62:cf02:: with SMTP id b2mr8497260pfg.183.1547622627622; Tue, 15 Jan 2019 23:10:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547622627; cv=none; d=google.com; s=arc-20160816; b=kBOD9U6XeYnX1EiUs5PgXItfT22UCrDed2KH1v2WE4ckQ5j/Ik9/0wn2F8vXdcP9iw VMldCHY6fOfoq7ChsDLd0YcF2aLAXU+VVIc3zVQv+vgfHX71ONejc1PyN7vsFSInTbT4 sygFjq9jfqCRJtzVPSpKNy4ImOsii5PObYTWrE25Kcg+6NoW4aczi3WoD2IDemlx3fD1 S/ggcoSXL2JJ50H8UVhT8Aimqc6FsHg927gY5eOrN3SdUPh0eGpHFWaVr9nQptH8+Y4o j/HeZsnoP8Qqn2jWnqKm1cJYBjQETXxGjXpWSDq4nPuW8NEUn6cum+CqTtVvQHoxSK7K l/dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=FLW84yJm9KbM1OoFE3utsganR8OPBeXYHN05HbnyItw=; b=HKxs5Hpjco8LZj2zokl4jmWxOV6Dx8EWkdWglgMdguu1S3Rj00gdKmLEOKK5p9nABT X1L/FsahvNH4HK2ZfEFEMds9dB5efnQQQwzq+VFJ/88DAm4+n39XIqqjKEOGedR9YkKJ 2gv5GMp4qwL3gYrpumqeK4xR3fi5rmhavD02NiYwCY+v1TPcJiqC5H/WmmvPPE3B76uW 8jfgINEE3fuVZfdN9iKOnnRoiryQXJutytl8ytx7CGjhFS+LT4VjjkCI0Kq2SNqjTvcM exrLOrd78ipmfFZ5EhvZB+qx5eExuYCOuCVR0FIFdIZEc8tuAzNA2UPD41ceUVrp26HO ugkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=OwUiKMHa; 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 r39si2404022pld.434.2019.01.15.23.10.09; Tue, 15 Jan 2019 23:10:27 -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-2018-07-02 header.b=OwUiKMHa; 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 S2388667AbfAOSJV (ORCPT + 99 others); Tue, 15 Jan 2019 13:09:21 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:58450 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729737AbfAOSJT (ORCPT ); Tue, 15 Jan 2019 13:09:19 -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 x0FI91lX067570; Tue, 15 Jan 2019 18:09:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=FLW84yJm9KbM1OoFE3utsganR8OPBeXYHN05HbnyItw=; b=OwUiKMHazbSFQHTZBm/a1dMvx2S5w4ozAqzqyTN0ST+B6lpI1QgXicZFB/KO2Gajw6jY lOCQcRl7/66fBIogK9TzkVUA5BvG+2Amv/hpDaYEtUDGcMm58jGaB0u2td/vonpLA8G2 fMnI0IfXe75hFjiVBBSnEaiYwiasTUv37YW5ga42xP40uzr65+S0Jh2k+kBEVXFpCWI+ AF0s1AqTtPpDtCj+/VGlALdEhrrou+IFLc9b+LYhPItijUUfjuM+gHZmQqZ41HngjFdf 90nlHBzrfkZ+2ZDyMme/BHjcAZtMliImqBlspzrtuSDj5iTW/CSeYNZgWdIqPfk+yaC4 bw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2pybjs5fb2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Jan 2019 18:09:02 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x0FI91hf020815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Jan 2019 18:09:02 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0FI90f7022642; Tue, 15 Jan 2019 18:09:00 GMT Received: from [192.168.1.164] (/50.38.38.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Jan 2019 10:09:00 -0800 Subject: Re: [RFC PATCH] mm: align anon mmap for THP To: "Kirill A. Shutemov" Cc: Steven Sistare , "Kirill A. Shutemov" , linux_lkml_grp@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hugh Dickins , Michal Hocko , Dan Williams , Matthew Wilcox , Toshi Kani , Boaz Harrosh , Andrew Morton References: <20190111201003.19755-1-mike.kravetz@oracle.com> <20190111215506.jmp2s5end2vlzhvb@black.fi.intel.com> <50c6abdc-b906-d16a-2f8f-8647b3d129aa@oracle.com> <20190115082450.stl6vlrgbvikbwzq@kshutemo-mobl1> From: Mike Kravetz Message-ID: <9a1c07f8-68d0-835c-6461-bb64fef977bf@oracle.com> Date: Tue, 15 Jan 2019 10:08:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190115082450.stl6vlrgbvikbwzq@kshutemo-mobl1> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9137 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 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-1810050000 definitions=main-1901150148 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/15/19 12:24 AM, Kirill A. Shutemov wrote: > On Mon, Jan 14, 2019 at 10:54:45AM -0800, Mike Kravetz wrote: >> On 1/14/19 7:35 AM, Steven Sistare wrote: >>> On 1/11/2019 6:28 PM, Mike Kravetz wrote: >>>> On 1/11/19 1:55 PM, Kirill A. Shutemov wrote: >>>>> On Fri, Jan 11, 2019 at 08:10:03PM +0000, Mike Kravetz wrote: >>>>>> At LPC last year, Boaz Harrosh asked why he had to 'jump through hoops' >>>>>> to get an address returned by mmap() suitably aligned for THP. It seems >>>>>> that if mmap is asking for a mapping length greater than huge page >>>>>> size, it should align the returned address to huge page size. >>> >>> A better heuristic would be to return an aligned address if the length >>> is a multiple of the huge page size. The gap (if any) between the end of >>> the previous VMA and the start of this VMA would be filled by subsequent >>> smaller mmap requests. The new behavior would need to become part of the >>> mmap interface definition so apps can rely on it and omit their hoop-jumping >>> code. >> >> Yes, the heuristic really should be 'length is a multiple of the huge page >> size'. As you mention, this would still leave gaps. I need to look closer >> but this may not be any worse than the trick of mapping an area with rounded >> up length and then unmapping pages at the beginning. > > The question why is it any better. Virtual address space is generally > cheap, additional VMA maybe more signficiant due to find_vma() overhead. > > And you don't *need* to unmap anything. Just use alinged pointer. You are correct, it is not any better. I know you do not need to unmap anything. However, I believe people are writing code which does this today. For example, qemu's qemu_ram_mmap() utility routine does this, but it may have other reasons for creating the gap. Thanks for all of the feedback. I do not think there is anything we can or should do in this area. As Steve said, 'power users' who want to get optimal THP usage will write the code to make that happen. -- Mike Kravetz