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 S1751576AbdJMP43 (ORCPT <rfc822;w@1wt.eu>);
        Fri, 13 Oct 2017 11:56:29 -0400
Received: from resqmta-po-09v.sys.comcast.net ([96.114.154.168]:40316 "EHLO
        resqmta-po-09v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1751378AbdJMP4Q (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 13 Oct 2017 11:56:16 -0400
Date: Fri, 13 Oct 2017 10:56:13 -0500 (CDT)
From: Christopher Lameter <cl@linux.com>
X-X-Sender: cl@nuc-kabylake
To: Michal Hocko <mhocko@kernel.org>
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>,
        Anshuman Khandual <khandual@linux.vnet.ibm.com>,
        Laura Abbott <labbott@redhat.com>, Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [RFC PATCH 3/3] mm/map_contig: Add mmap(MAP_CONTIG) support
In-Reply-To: <20171013154747.2jv7rtfqyyagiodn@dhcp22.suse.cz>
Message-ID: <alpine.DEB.2.20.1710131053450.4400@nuc-kabylake>
References: <21f1ec96-2822-1189-1c95-79a2bb491571@oracle.com> <20171012014611.18725-1-mike.kravetz@oracle.com> <20171012014611.18725-4-mike.kravetz@oracle.com> <20171012143756.p5bv4zx476qkmqhh@dhcp22.suse.cz> <f4a46a19-5f71-ebcc-3098-a35728fbfd03@oracle.com>
 <20171013084054.me3kxhgbxzgm2lpr@dhcp22.suse.cz> <alpine.DEB.2.20.1710131015420.3949@nuc-kabylake> <20171013152801.nbpk6nluotgbmfrs@dhcp22.suse.cz> <alpine.DEB.2.20.1710131040570.4247@nuc-kabylake> <20171013154747.2jv7rtfqyyagiodn@dhcp22.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: MS4wfBd2YjWppPPdjQKHJWKQTRRwHndd47VHnvVOov2PeNcRU38dZWn9HBONxmhqyVGEyL2d0U8HmJeigHHruTfbcoEUnfH4Qy1J/ibZ1FMI6cGRkCOeKmNP
 EF00QpCYYplcGVz8JrvFGNggd3aS+mkK8kEfFBFhRIh2FepbUsrO9tGqi6z4RoU4ix8JxqxR1tongjigg+08FZOWISPGI2xCnJn5AV7AsrJHqBBDD1ABDexH
 vdfpBiLIskM51cbTQ/t1JQKZhKaLvrLMSMPiGk9hRBab0nWLBUeW79oYUBCdXnUoWYcwLoTddY1Aau7N4I638Mehqj9l1l4s1KNhQTfGqV7hP9UCDP8AQv+Y
 MVf6BRG2hFIjtgQY5AXgT1KsnrXWechqj37N3zP2jtswUNtu6ajmmVtzw2ZZTvs4kMCZ/Hf8uMd2JJRa06z/ZWWhjcdzvEjcULCpwz+ZcIwvl1mSSgSamtmy
 UwRiirPXuG3dFYXX7r1uHHk2isjk4KqDE6zFnMsp87XlfhvkU3V7Lmt4g4J+wyjIZEmA+COUePhZzuxdDLzhHrrGLcSsFZD9ei0O4w==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 13 Oct 2017, Michal Hocko wrote:

> > There is a generic posix interface that could we used for a variety of
> > specific hardware dependent use cases.
>
> Yes you wrote that already and my counter argument was that this generic
> posix interface shouldn't bypass virtual memory abstraction.

It does do that? In what way?

> > There are numerous RDMA devices that would all need the mmap
> > implementation. And this covers only the needs of one subsystem. There are
> > other use cases.
>
> That doesn't prevent providing a library function which could be reused
> by all those drivers. Nothing really too much different from
> remap_pfn_range.

And then in all the other use cases as well. It would be much easier if
mmap could give you the memory you need instead of havig numerous drivers
improvise on their own. This is in particular also useful
for numerous embedded use cases where you need contiguous memory.