From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g9t5008.houston.hp.com (g9t5008.houston.hp.com [15.240.92.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B2D7F1A1F32 for ; Thu, 7 Apr 2016 14:29:00 -0700 (PDT) Message-ID: <1460064033.20338.74.camel@hpe.com> Subject: Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap From: Toshi Kani Date: Thu, 07 Apr 2016 15:20:33 -0600 In-Reply-To: <20160407174111.GG2781@linux.intel.com> References: <1459951089-14911-1-git-send-email-toshi.kani@hpe.com> <20160406165027.GA2781@linux.intel.com> <1459964672.20338.41.camel@hpe.com> <20160407174111.GG2781@linux.intel.com> Mime-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Matthew Wilcox Cc: linux-nvdimm@lists.01.org, x86@kernel.org, linux-kernel@vger.kernel.org, mingo@kernel.org, linux-mm@kvack.org, hpa@zytor.com, tglx@linutronix.de, bp@suse.de, kirill.shutemov@linux.intel.com List-ID: T24gVGh1LCAyMDE2LTA0LTA3IGF0IDEzOjQxIC0wNDAwLCBNYXR0aGV3IFdpbGNveCB3cm90ZToK PiBPbiBXZWQsIEFwciAwNiwgMjAxNiBhdCAxMTo0NDozMkFNIC0wNjAwLCBUb3NoaSBLYW5pIHdy b3RlOgo+ID4gPiAKPiA+ID4gVGhlIE5WTUwgY2hvb3NlcyBhcHByb3ByaWF0ZSBhZGRyZXNzZXMg YW5kIGdldHMgYSBwcm9wZXJseSBhbGlnbmVkCj4gPiA+IGFkZHJlc3Mgd2l0aG91dCBhbnkga2Vy bmVsIGNvZGUuCj4gPgo+ID4gQW4gYXBwbGljYXRpb24gbGlrZSBOVk1MIGNhbiBjb250aW51ZSB0 byBzcGVjaWZ5IGEgc3BlY2lmaWMgYWRkcmVzcyB0bwo+ID4gbW1hcCgpLiDCoE1vc3QgZXhpc3Rp bmcgYXBwbGljYXRpb25zLCBob3dldmVyLCBkbyBub3Qgc3BlY2lmeSBhbiBhZGRyZXNzCj4gPiB0 byBtbWFwKCkuIMKgV2l0aCB0aGlzIHBhdGNoLCBzcGVjaWZ5aW5nIGFuIGFkZHJlc3Mgd2lsbCBy ZW1haW4KPiA+IG9wdGlvbmFsLgo+Cj4gVGhlIHBvaW50IGlzIHRoYXQgdGhpcyAqY2FuKiBiZSBk b25lIGluIHVzZXJzcGFjZS7CoMKgWW91IG5lZWQgdG8gc2VsbCB1cwo+IG9uIHRoZSBhZHZhbnRh Z2VzIG9mIGRvaW5nIGl0IGluIHRoZSBrZXJuZWwuCgpTdXJlLiDCoEFzIEkgc2FpZCwgdGhlIHBv aW50IGlzIHRoYXQgd2UgZG8gbm90IG5lZWQgdG8gbW9kaWZ5IGV4aXN0aW5nCmFwcGxpY2F0aW9u cyBmb3IgdXNpbmcgREFYIFBNRCBtYXBwaW5ncy4KCkZvciBpbnN0YW5jZSwgZmlvIHdpdGggImlv ZW5naW5lPW1tYXAiIHBlcmZvcm1zIEkvT3Mgd2l0aCBtbWFwKCkuCmh0dHBzOi8vZ2l0aHViLmNv bS9jYWl1cy9maW8vYmxvYi9tYXN0ZXIvZW5naW5lcy9tbWFwLmMKCldpdGggdGhpcyBjaGFuZ2Us IHVubW9kaWZpZWQgZmlvIGNhbiBiZSB1c2VkIGZvciB0ZXN0aW5nIHdpdGggREFYIFBNRAptYXBw aW5ncy4gwqBUaGVyZSBhcmUgbWFueSBleGFtcGxlcyBsaWtlIHRoaXMsIGFuZCBJIGRvIG5vdCB0 aGluayB3ZSB3YW50IHRvCm1vZGlmeSBhbGwgYXBwbGljYXRpb25zIHRoYXQgd2Ugd2FudCB0byBl dmFsdWF0ZS90ZXN0IHdpdGguCgo+ID4gPiBJIHRoaW5rIHRoaXMgaXMgdGhlIHdyb25nIHBsYWNl IGZvciBpdCwgaWYgd2UgZGVjaWRlIHRoYXQgdGhpcyBpcyB0aGUKPiA+ID4gcmlnaHQgdGhpbmcg dG8gZG8uwqDCoFRoZSBmaWxlc3lzdGVtIGhhcyBhIGdldF91bm1hcHBlZF9hcmVhKCkgd2hpY2gK PiA+ID4gc2hvdWxkIGJlIHVzZWQgaW5zdGVhZC4KPiA+Cj4gPiBZZXMsIEkgY29uc2lkZXJlZCBh ZGRpbmcgYSBmaWxlc3lzdGVtIGVudHJ5IHBvaW50LCBidXQgZGVjaWRlZCBnb2luZwo+ID4gdGhp cyB3YXkgYmVjYXVzZToKPiA+IMKgLcKgYXJjaF9nZXRfdW5tYXBwZWRfYXJlYSgpIGFuZMKgYXJj aF9nZXRfdW5tYXBwZWRfYXJlYV90b3Bkb3duKCkgYXJlCj4gPiBhcmNoLXNwZWNpZmljIGNvZGUu IMKgVGhlcmVmb3JlLCB0aGlzIGZpbGVzeXN0ZW0gZW50cnkgcG9pbnQgd2lsbCBuZWVkCj4gPiBh cmNoLXNwZWNpZmljIGltcGxlbWVudGF0aW9uLsKgCj4gPiDCoC0gVGhlcmUgaXMgbm90aGluZyBm aWxlc3lzdGVtIHNwZWNpZmljIGFib3V0IHJlcXVlc3RpbmcgUE1EIGFsaWdubWVudC4KPgo+IFNl ZSBodHRwOi8vYXJ0aWNsZS5nbWFuZS5vcmcvZ21hbmUubGludXgua2VybmVsLm1tLzE0OTIyNyBm b3IgSHVnaCdzCj4gYXBwcm9hY2ggZm9yIHNobWVtLsKgwqBJIHN0cm9uZ2x5IGJlbGlldmUgdGhh dCBpZiB3ZSdyZSBnb2luZyB0byBkbyB0aGlzCj4gaSB0aGUga2VybmVsLCB3ZSBzaG91bGQgYnVp bGQgb24gdGhpcyBhcHByb2FjaCwgYW5kIG5vdCBoYWNrIHNvbWV0aGluZwo+IGludG8gZWFjaCBh cmNoaXRlY3R1cmUncyBnZW5lcmljIGdldF91bm1hcHBlZF9hcmVhLgoKVGhhbmtzIGZvciB0aGUg cG9pbnRlci4gwqBZZXMsIHdlIGNhbiBjYWxsIGN1cnJlbnQtPm1tLT5nZXRfdW5tYXBwZWRfYXJl YSgpCndpdGggc2l6ZSArIFBNRF9TSVpFLCBhbmQgYWRqdXN0IHdpdGggdGhlIGFsaWdubWVudCBp biBhIGZpbGVzeXN0ZW0gZW50cnkKcG9pbnQuIMKgSSB3aWxsIHVwZGF0ZSB0aGUgcGF0Y2ggd2l0 aCB0aGlzIGFwcHJvYWNoLgoKLVRvc2hpCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCkxpbnV4LW52ZGltbSBtYWlsaW5nIGxpc3QKTGludXgtbnZkaW1tQGxp c3RzLjAxLm9yZwpodHRwczovL2xpc3RzLjAxLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW52 ZGltbQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by kanga.kvack.org (Postfix) with ESMTP id CE1976B0005 for ; Thu, 7 Apr 2016 17:29:00 -0400 (EDT) Received: by mail-ob0-f178.google.com with SMTP id fp4so61302317obb.2 for ; Thu, 07 Apr 2016 14:29:00 -0700 (PDT) Received: from g9t5008.houston.hp.com (g9t5008.houston.hp.com. [15.240.92.66]) by mx.google.com with ESMTPS id sw5si3544471obc.4.2016.04.07.14.29.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Apr 2016 14:29:00 -0700 (PDT) Message-ID: <1460064033.20338.74.camel@hpe.com> Subject: Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap From: Toshi Kani Date: Thu, 07 Apr 2016 15:20:33 -0600 In-Reply-To: <20160407174111.GG2781@linux.intel.com> References: <1459951089-14911-1-git-send-email-toshi.kani@hpe.com> <20160406165027.GA2781@linux.intel.com> <1459964672.20338.41.camel@hpe.com> <20160407174111.GG2781@linux.intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: mingo@kernel.org, bp@suse.de, hpa@zytor.com, tglx@linutronix.de, dan.j.williams@intel.com, kirill.shutemov@linux.intel.com, linux-mm@kvack.org, x86@kernel.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org On Thu, 2016-04-07 at 13:41 -0400, Matthew Wilcox wrote: > On Wed, Apr 06, 2016 at 11:44:32AM -0600, Toshi Kani wrote: > > > > > > The NVML chooses appropriate addresses and gets a properly aligned > > > address without any kernel code. > > > > An application like NVML can continue to specify a specific address to > > mmap(). A Most existing applications, however, do not specify an address > > to mmap(). A With this patch, specifying an address will remain > > optional. > > The point is that this *can* be done in userspace.A A You need to sell us > on the advantages of doing it in the kernel. Sure. A As I said, the point is that we do not need to modify existing applications for using DAX PMD mappings. For instance, fio with "ioengine=mmap" performs I/Os with mmap(). https://github.com/caius/fio/blob/master/engines/mmap.c With this change, unmodified fio can be used for testing with DAX PMD mappings. A There are many examples like this, and I do not think we want to modify all applications that we want to evaluate/test with. > > > I think this is the wrong place for it, if we decide that this is the > > > right thing to do.A A The filesystem has a get_unmapped_area() which > > > should be used instead. > > > > Yes, I considered adding a filesystem entry point, but decided going > > this way because: > > A -A arch_get_unmapped_area() andA arch_get_unmapped_area_topdown() are > > arch-specific code. A Therefore, this filesystem entry point will need > > arch-specific implementation.A > > A - There is nothing filesystem specific about requesting PMD alignment. > > See http://article.gmane.org/gmane.linux.kernel.mm/149227 for Hugh's > approach for shmem.A A I strongly believe that if we're going to do this > i the kernel, we should build on this approach, and not hack something > into each architecture's generic get_unmapped_area. Thanks for the pointer. A Yes, we can call current->mm->get_unmapped_area() with size + PMD_SIZE, and adjust with the alignment in a filesystem entry point. A I will update the patch with this approach. -Toshi -- 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 S1757633AbcDGV3D (ORCPT ); Thu, 7 Apr 2016 17:29:03 -0400 Received: from g9t5008.houston.hp.com ([15.240.92.66]:46894 "EHLO g9t5008.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757219AbcDGV3B (ORCPT ); Thu, 7 Apr 2016 17:29:01 -0400 Message-ID: <1460064033.20338.74.camel@hpe.com> Subject: Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap From: Toshi Kani To: Matthew Wilcox Cc: mingo@kernel.org, bp@suse.de, hpa@zytor.com, tglx@linutronix.de, dan.j.williams@intel.com, kirill.shutemov@linux.intel.com, linux-mm@kvack.org, x86@kernel.org, linux-nvdimm@ml01.01.org, linux-kernel@vger.kernel.org Date: Thu, 07 Apr 2016 15:20:33 -0600 In-Reply-To: <20160407174111.GG2781@linux.intel.com> References: <1459951089-14911-1-git-send-email-toshi.kani@hpe.com> <20160406165027.GA2781@linux.intel.com> <1459964672.20338.41.camel@hpe.com> <20160407174111.GG2781@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-04-07 at 13:41 -0400, Matthew Wilcox wrote: > On Wed, Apr 06, 2016 at 11:44:32AM -0600, Toshi Kani wrote: > > > > > > The NVML chooses appropriate addresses and gets a properly aligned > > > address without any kernel code. > > > > An application like NVML can continue to specify a specific address to > > mmap().  Most existing applications, however, do not specify an address > > to mmap().  With this patch, specifying an address will remain > > optional. > > The point is that this *can* be done in userspace.  You need to sell us > on the advantages of doing it in the kernel. Sure.  As I said, the point is that we do not need to modify existing applications for using DAX PMD mappings. For instance, fio with "ioengine=mmap" performs I/Os with mmap(). https://github.com/caius/fio/blob/master/engines/mmap.c With this change, unmodified fio can be used for testing with DAX PMD mappings.  There are many examples like this, and I do not think we want to modify all applications that we want to evaluate/test with. > > > I think this is the wrong place for it, if we decide that this is the > > > right thing to do.  The filesystem has a get_unmapped_area() which > > > should be used instead. > > > > Yes, I considered adding a filesystem entry point, but decided going > > this way because: > >  - arch_get_unmapped_area() and arch_get_unmapped_area_topdown() are > > arch-specific code.  Therefore, this filesystem entry point will need > > arch-specific implementation.  > >  - There is nothing filesystem specific about requesting PMD alignment. > > See http://article.gmane.org/gmane.linux.kernel.mm/149227 for Hugh's > approach for shmem.  I strongly believe that if we're going to do this > i the kernel, we should build on this approach, and not hack something > into each architecture's generic get_unmapped_area. Thanks for the pointer.  Yes, we can call current->mm->get_unmapped_area() with size + PMD_SIZE, and adjust with the alignment in a filesystem entry point.  I will update the patch with this approach. -Toshi