From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Nazarewicz Subject: Re: [RFC PATCH 3/3] mm/map_contig: Add mmap(MAP_CONTIG) support Date: Mon, 16 Oct 2017 12:33:07 +0200 Message-ID: References: <20171012014611.18725-1-mike.kravetz@oracle.com> <20171012014611.18725-4-mike.kravetz@oracle.com> <20171012143756.p5bv4zx476qkmqhh@dhcp22.suse.cz> <20171013084054.me3kxhgbxzgm2lpr@dhcp22.suse.cz> <20171013152801.nbpk6nluotgbmfrs@dhcp22.suse.cz> <20171013154747.2jv7rtfqyyagiodn@dhcp22.suse.cz> <20171013161736.htumyr4cskfrjq64@dhcp22.suse.cz> <752b49eb-55c6-5a34-ab41-6e91dd93ea70@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <752b49eb-55c6-5a34-ab41-6e91dd93ea70-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Guy Shattah , Michal Hocko , Christopher Lameter Cc: Mike Kravetz , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Marek Szyprowski , "Aneesh Kumar K . V" , Joonsoo Kim , Anshuman Khandual , Laura Abbott , Vlastimil Babka List-Id: linux-api@vger.kernel.org On Sun, Oct 15 2017, Guy Shattah wrote: > Why have several driver specific implementation if you can generalize > the idea and implement an already existing POSIX standard? Why is there a need for contiguous allocation? CPU cares only to the point of huge pages and there=E2=80=99s already an ef= fort in the kernel to allocate huge pages transparently without user space being aware of it. If not CPU than various devices all of which may have very different needs. Some may be behind an IO MMU. Some may support DMA. Some may indeed require physically continuous memory. How is user space to know? Furthermore, user space does not care whether allocation is physically contiguous or not. What it cares about is whether given allocation can be passed as a buffer to a particular device. If generalisation is the issue, then the solution is to define a common API where user-space can allocate memory *in the context of* a device. This provides a =E2=80=98give me memory I can use for this device=E2=80=99 = request which is what user space really wants. So yeah, like others in this thread, the reason for this change alludes me. On the other hand, I don=E2=80=99t care much so I=E2=80=99ll limit mys= elf to this one message. --=20 Best regards =E3=83=9F=E3=83=8F=E3=82=A6 =E2=80=9C=F0=9D=93=B6=F0=9D=93=B2=F0=9D=93=B7= =F0=9D=93=AA86=E2=80=9D =E3=83=8A=E3=82=B6=E3=83=AC=E3=83=B4=E3=82=A4=E3=83= =84 =C2=ABIf at first you don=E2=80=99t succeed, give up skydiving=C2=BB From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id 67D686B0033 for ; Mon, 16 Oct 2017 06:33:12 -0400 (EDT) Received: by mail-wm0-f71.google.com with SMTP id t69so8780116wmt.7 for ; Mon, 16 Oct 2017 03:33:12 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id j9sor3346898edf.30.2017.10.16.03.33.10 for (Google Transport Security); Mon, 16 Oct 2017 03:33:10 -0700 (PDT) From: Michal Nazarewicz Subject: Re: [RFC PATCH 3/3] mm/map_contig: Add mmap(MAP_CONTIG) support In-Reply-To: <752b49eb-55c6-5a34-ab41-6e91dd93ea70@mellanox.com> References: <20171012014611.18725-1-mike.kravetz@oracle.com> <20171012014611.18725-4-mike.kravetz@oracle.com> <20171012143756.p5bv4zx476qkmqhh@dhcp22.suse.cz> <20171013084054.me3kxhgbxzgm2lpr@dhcp22.suse.cz> <20171013152801.nbpk6nluotgbmfrs@dhcp22.suse.cz> <20171013154747.2jv7rtfqyyagiodn@dhcp22.suse.cz> <20171013161736.htumyr4cskfrjq64@dhcp22.suse.cz> <752b49eb-55c6-5a34-ab41-6e91dd93ea70@mellanox.com> Date: Mon, 16 Oct 2017 12:33:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Guy Shattah , Michal Hocko , Christopher Lameter Cc: Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Marek Szyprowski , "Aneesh Kumar K . V" , Joonsoo Kim , Anshuman Khandual , Laura Abbott , Vlastimil Babka On Sun, Oct 15 2017, Guy Shattah wrote: > Why have several driver specific implementation if you can generalize > the idea and implement an already existing POSIX standard? Why is there a need for contiguous allocation? CPU cares only to the point of huge pages and there=E2=80=99s already an ef= fort in the kernel to allocate huge pages transparently without user space being aware of it. If not CPU than various devices all of which may have very different needs. Some may be behind an IO MMU. Some may support DMA. Some may indeed require physically continuous memory. How is user space to know? Furthermore, user space does not care whether allocation is physically contiguous or not. What it cares about is whether given allocation can be passed as a buffer to a particular device. If generalisation is the issue, then the solution is to define a common API where user-space can allocate memory *in the context of* a device. This provides a =E2=80=98give me memory I can use for this device=E2=80=99 = request which is what user space really wants. So yeah, like others in this thread, the reason for this change alludes me. On the other hand, I don=E2=80=99t care much so I=E2=80=99ll limit mys= elf to this one message. --=20 Best regards =E3=83=9F=E3=83=8F=E3=82=A6 =E2=80=9C=F0=9D=93=B6=F0=9D=93=B2=F0=9D=93=B7= =F0=9D=93=AA86=E2=80=9D =E3=83=8A=E3=82=B6=E3=83=AC=E3=83=B4=E3=82=A4=E3=83= =84 =C2=ABIf at first you don=E2=80=99t succeed, give up skydiving=C2=BB -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751865AbdJPKdO (ORCPT ); Mon, 16 Oct 2017 06:33:14 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:48491 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750914AbdJPKdL (ORCPT ); Mon, 16 Oct 2017 06:33:11 -0400 X-Google-Smtp-Source: AOwi7QCa9jcBl7dxrXhSG7mM8E/gvDC2d8YyG0ZI29fi1g5elKNHiv8PkoocKdS7u3NM8G2GRkjL8A== From: Michal Nazarewicz To: Guy Shattah , Michal Hocko , Christopher Lameter Cc: Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Marek Szyprowski , "Aneesh Kumar K . V" , Joonsoo Kim , Anshuman Khandual , Laura Abbott , Vlastimil Babka Subject: Re: [RFC PATCH 3/3] mm/map_contig: Add mmap(MAP_CONTIG) support In-Reply-To: <752b49eb-55c6-5a34-ab41-6e91dd93ea70@mellanox.com> Organization: http://mina86.com/ References: <20171012014611.18725-1-mike.kravetz@oracle.com> <20171012014611.18725-4-mike.kravetz@oracle.com> <20171012143756.p5bv4zx476qkmqhh@dhcp22.suse.cz> <20171013084054.me3kxhgbxzgm2lpr@dhcp22.suse.cz> <20171013152801.nbpk6nluotgbmfrs@dhcp22.suse.cz> <20171013154747.2jv7rtfqyyagiodn@dhcp22.suse.cz> <20171013161736.htumyr4cskfrjq64@dhcp22.suse.cz> <752b49eb-55c6-5a34-ab41-6e91dd93ea70@mellanox.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWbfGlUPDDHgE57V0jUupKjgIObY0PLrom9mH4dFRK4gmjPs41MxjOgAAACP0lEQVQ4T23Sv2vbQBQHcBk1xE6WyALX107VUEgmn6+ouUwpEQQ6uRjttkWP4CkBg2M0BQLBdPFZYPsyFYo7qEtKDQ7on+t7+nF2Ux8ahD587717OmNYrOvycHsZ+o2r051wHTHysAvGb8ygvgu4QWT0sCmkgZCIEnlV2X8BtyraazFGDuxhmKSQJMlwHQ7v5MHSNxmz78rfElwAa3ieVD9e+hBhjaPDDG6NgFo2f4wBMNIo5YmRtF0RyDgFjJjlMIWbnuM4x9MMfABGTlN4qgIQB4A1DEyA1BHWtfeWNUMwiVJKoqh97KrkOO+qzgluVYLvFCUKAX73nONeBr7BGMdM6Sg0kuep03VywLaIzRiVr+GAzKlpQIsAFnWAG2e6DT5WmWDiudZMIc6hYrMOmeMQK9WX0B+/RfjzL9DI7Y9/Iayn29Ci0r2i4f9gMimMSZLCDMalgQGU5hnUtqAN0OGvEmO1Wnl0C0wWSCEHnuHBqmygxdxA8oWXwbipoc1EoNR9DqOpBpOJrnr0criQab9ZT4LL+wI+K7GBQH30CrhUruilgP9DRTrhVWZCiAyILP+wiuLeCKGTD6r/nc8LOJcAwR6IBTUs+7CASw3QFZ0MdA2PI3zNziH4ZKVhXCRMBjeZ1DWMekKwDCASwExy+NQ86TaykaDAFHO4aP48y4fIcDM5yOG8GcTLbOyp8A8azjJI93JFd1EA6yN8sSxMQJWoABqniRZVykYgRXErzrdqExAoUrRb0xfRp8p2A/4XmfilTtkDZ4cAAAAASUVORK5CYII= X-Face: -TR8(rDTHy/(xl?SfWd1|3:TTgDIatE^t'vop%*gVg[kn$t{EpK(P"VQ=~T2#ysNmJKN$"yTRLB4YQs$4{[.]Fc1)*O]3+XO^oXM>Q#b^ix,O)Zbn)q[y06$`e3?C)`CwR9y5riE=fv^X@x$y?D:XO6L&x4f-}}I4=VRNwiA^t1-ZrVK^07.Pi/57c_du'& OpenPGP: id=AC1F5F5CD41888F8CC8458582060401250751FF4; url=http://mina86.com/mina86.pub X-Hashcash: 1:20:171016:khandual@linux.vnet.ibm.com::AISN5J4/0UCOpjQm:00000000000000000000000000000000000EbU X-Hashcash: 1:20:171016:linux-api@vger.kernel.org::iws0C4RPxoJc1Pls:000000000000000000000000000000000000040D X-Hashcash: 1:20:171016:mhocko@kernel.org::nzPIlorKPVBHEqbh:000000000000000000000000000000000000000000000lRW X-Hashcash: 1:20:171016:vbabka@suse.cz::REK8JTLKONIZueul:0001ZkP X-Hashcash: 1:20:171016:labbott@redhat.com::vT0Putlq6dqywPx0:00000000000000000000000000000000000000000003MfE X-Hashcash: 1:20:171016:aneesh.kumar@linux.vnet.ibm.com::rui05SXDlJUwfQtc:0000000000000000000000000000002MRM X-Hashcash: 1:20:171016:linux-kernel@vger.kernel.org::xXOsE01QDaav6vrU:0000000000000000000000000000000001wey X-Hashcash: 1:20:171016:linux-mm@kvack.org::tGKFDtGgBu2YE+3r:00000000000000000000000000000000000000000006c5e X-Hashcash: 1:20:171016:mike.kravetz@oracle.com::tacfCurzQoTBVYP5:000000000000000000000000000000000000002T/C X-Hashcash: 1:20:171016:cl@linux.com::vOC69gSfSXvsOtlW:000002NST X-Hashcash: 1:20:171016:sguy@mellanox.com::62neKlXzIL1UVB2o:000000000000000000000000000000000000000000005sw1 X-Hashcash: 1:20:171016:iamjoonsoo.kim@lge.com::ZL/5GnneEYhkqf0y:0000000000000000000000000000000000000006GaY X-Hashcash: 1:20:171016:m.szyprowski@samsung.com::TzqybxhRw4zEW/dr:0000000000000000000000000000000000000Ddpo Date: Mon, 16 Oct 2017 12:33:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v9GAXLOj004597 On Sun, Oct 15 2017, Guy Shattah wrote: > Why have several driver specific implementation if you can generalize > the idea and implement an already existing POSIX standard? Why is there a need for contiguous allocation? CPU cares only to the point of huge pages and there’s already an effort in the kernel to allocate huge pages transparently without user space being aware of it. If not CPU than various devices all of which may have very different needs. Some may be behind an IO MMU. Some may support DMA. Some may indeed require physically continuous memory. How is user space to know? Furthermore, user space does not care whether allocation is physically contiguous or not. What it cares about is whether given allocation can be passed as a buffer to a particular device. If generalisation is the issue, then the solution is to define a common API where user-space can allocate memory *in the context of* a device. This provides a ‘give me memory I can use for this device’ request which is what user space really wants. So yeah, like others in this thread, the reason for this change alludes me. On the other hand, I don’t care much so I’ll limit myself to this one message. -- Best regards ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ «If at first you don’t succeed, give up skydiving»