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 S1751657AbdJEOa0 (ORCPT <rfc822;w@1wt.eu>);
        Thu, 5 Oct 2017 10:30:26 -0400
Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43]:41208 "EHLO
        resqmta-ch2-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1751083AbdJEOaY (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 5 Oct 2017 10:30:24 -0400
Date: Thu, 5 Oct 2017 09:30:22 -0500 (CDT)
From: Christopher Lameter <cl@linux.com>
X-X-Sender: cl@nuc-kabylake
To: Vlastimil Babka <vbabka@suse.cz>
cc: Mike Kravetz <mike.kravetz@oracle.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
        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>
Subject: Re: [RFC] mmap(MAP_CONTIG)
In-Reply-To: <3c28baa4-f8f5-a86e-4830-bf3c7c74ed4f@suse.cz>
Message-ID: <alpine.DEB.2.20.1710050928040.2543@nuc-kabylake>
References: <21f1ec96-2822-1189-1c95-79a2bb491571@oracle.com> <3c28baa4-f8f5-a86e-4830-bf3c7c74ed4f@suse.cz>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-CMAE-Envelope: MS4wfA9fRezhpK1mrstOs+p1TGoBwYYYDfekTQeeDBcW4wxEIhdOVo3KVpFbSPt1pjsEelNafTNwpyJbHSpe8XU5y3GxFPSnPhDJaUvExc5a3C1jDw0VeRvi
 xLB520u1ZwMi5CV7fThv1niKMcKQQn21M2LF59T8PEhdpj80Xed7vYFlWRVSgLvDUhV7p8xzoHqMa4SofCbwfgwlZPBFmCLMab3Gbzohn7O2gtP2vHzrt7MZ
 798NXA6TkdfDRIYC3MNW7IpopNtS4jjMlEDWEswpjB3EGPjWTYg6TEj9U1drm8AtWoBcXF9i61OVIYRVZwo5kAiLREAm9aPBzBVkl7AQ4DGl6jy/Rh6oWfEa
 ikbs0nL1YVE0TkcWYK47TUvYJBkbN9E1uTKYWZ+YLZz0lgVyoWsCKxVcd/bXvxMcdGvDLUlFWOlVtPHKSYNLk0tSn5th8l5CaDdesSRHKkOjyqrRfUo=
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 5 Oct 2017, Vlastimil Babka wrote:

> On 10/04/2017 01:56 AM, Mike Kravetz wrote:
> > At Plumbers this year, Guy Shattah and Christoph Lameter gave a presentation
> > titled 'User space contiguous memory allocation for DMA' [1].  The slides
> Hm I didn't find slides on that link, are they available?

I just added Guy's slides to the entry.

> As Michal N. noted, the drivers might have different requirements. Is
> contiguity (without extra requirements) so common that it would benefit
> from a userspace API change?

Yes.

> Also how are the driver-specific allocations done today? mmap() on the
> driver's device? Maybe we could provide some in-kernel API/library to
> make them less "ad-hoc". Conversion to MAP_ANONYMOUS would at first seem
> like an improvement in that userspace would be able to use a generic
> allocation API and all the generic treatment of anonymous pages (LRU
> aging, reclaim, migration etc), but the restrictions you listed below
> eliminate most of that?
> (It's likely that I just don't have enough info about how it works today
> so it's difficult to judge)

Contemporary devices typically can address all of memory. Moreover the
device used actually can trigger faults to page in 4k pages if they are
not present (ODP in RDMA layer). There is no need for driver specific
allocation in those drivers.