From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755110AbdJLKgf (ORCPT <rfc822;w@1wt.eu>);
        Thu, 12 Oct 2017 06:36:35 -0400
Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:37316 "EHLO
        mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL)
        by vger.kernel.org with ESMTP id S1752529AbdJLKgd (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 12 Oct 2017 06:36:33 -0400
Subject: Re: [RFC PATCH 0/3] Add mmap(MAP_CONTIG) support
To: Mike Kravetz <mike.kravetz@oracle.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
References: <21f1ec96-2822-1189-1c95-79a2bb491571@oracle.com>
 <20171012014611.18725-1-mike.kravetz@oracle.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
        Michal Nazarewicz <mina86@mina86.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>, Guy Shattah <sguy@mellanox.com>,
        Christoph Lameter <cl@linux.com>,
        Anshuman Khandual <khandual@linux.vnet.ibm.com>,
        Laura Abbott <labbott@redhat.com>, Vlastimil Babka <vbabka@suse.cz>
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Date: Thu, 12 Oct 2017 16:06:13 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20171012014611.18725-1-mike.kravetz@oracle.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-TM-AS-MML: disable
x-cbid: 17101210-0008-0000-0000-0000049F1ADE
X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused
x-cbparentid: 17101210-0009-0000-0000-00001E312D47
Message-Id: <f1737666-b65e-38e2-94af-129e66031503@linux.vnet.ibm.com>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-12_05:,,
 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0
 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000
 definitions=main-1710120151
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/12/2017 07:16 AM, Mike Kravetz wrote:
> The following is a 'possible' way to add such functionality.  I just
> did what was easy and pre-allocated contiguous pages which are used
> to populate the mapping.  I did not use any of the higher order
> allocators such as alloc_contig_range.  Therefore, it is limited to

Just tried with a small prototype with an implementation similar to that
of alloc_gigantic_page() where we scan the zones (applicable zonelist)
for contiguous valid PFN range and try allocating with alloc_contig_range.
Will share it soon.

> allocations of MAX_ORDER size.  Also, the allocations should probably

Just did a quick test and it worked till 1UL << (MAX_ORDER - 1) numbers
of pages on a POWER system with the current RFC patches. As the pages
are allocated during VMA creation time, comparison to normal page fault
speed while accessing the buffer wont be fair.

> be done outside mmap_sem but that was the easiest place to do it in
> this quick and easy POC.

Why it should be done outside the mmap_sem, because it can take some
time ? But then VMA can just go away while we are allocating the big
chunks of pages (if we dont hold mmap_sem).