From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756668AbcH2Vci (ORCPT ); Mon, 29 Aug 2016 17:32:38 -0400 Received: from mail-by2nam03on0100.outbound.protection.outlook.com ([104.47.42.100]:48800 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753322AbcH2Vcg (ORCPT ); Mon, 29 Aug 2016 17:32:36 -0400 X-Greylist: delayed 2856 seconds by postgrey-1.27 at vger.kernel.org; Mon, 29 Aug 2016 17:32:36 EDT From: "Kani, Toshimitsu" To: "kirill@shutemov.name" CC: "hughd@google.com" , "kirill.shutemov@linux.intel.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "adilger.kernel@dilger.ca" , "mike.kravetz@oracle.com" , "dan.j.williams@intel.com" , "mawilcox@microsoft.com" , "akpm@linux-foundation.org" , "linux-nvdimm@lists.01.org" , "linux-fsdevel@vger.kernel.org" , "ross.zwisler@linux.intel.com" , "tytso@mit.edu" , "david@fromorbit.com" , "jack@suse.cz" Subject: Re: [PATCH v4 RESEND 0/2] Align mmap address for DAX pmd mappings Thread-Topic: [PATCH v4 RESEND 0/2] Align mmap address for DAX pmd mappings Thread-Index: AQHSAilHX/y+euft+0Ox/nTogkvaQaBgaSEAgAAMDQA= Date: Mon, 29 Aug 2016 21:32:32 +0000 Message-ID: <1472506310.1532.47.camel@hpe.com> References: <1472497881-9323-1-git-send-email-toshi.kani@hpe.com> <20160829204842.GA27286@node.shutemov.name> In-Reply-To: <20160829204842.GA27286@node.shutemov.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=toshi.kani@hpe.com; x-originating-ip: [15.219.163.2] x-ms-office365-filtering-correlation-id: d55619ba-e044-4742-60ac-08d3d053fc8c x-microsoft-exchange-diagnostics: 1;CS1PR84MB0005;6:geQepWz6VDkRqkgf5Y00s+TXMH/ZDN7YEU9RMWIyKRIkyrPfhBUtxRYXa32MbmmTD0clEOYsXgku0KK/WsjB3vT+YwBAEPJgGPJmd6wl4HZgcjUopoWvb0s6enzvXVeY8+drzVzOwef+5vkhrTcZ2IJZo/FyhziJsC64Ow5nHK8GtvXMF7ato0iLk0nZTxbo0dG5DG64g/ca8MbVbJqvQc2s6w561tMY/W40vYErtUZBaB1NxF77USXU5ZJQBParmLwm+ZQq9pZQyiVSYSl7he3Wmikszu20zdUhaux0wd22jDjJ6BASmRIzK32C8UasGea+kYRbWDDtwGrwxbD/dA==;5:m46VDZZcrqTDacSyx0jXU3MvpP2kx7ABtBCJbPSSCUPRGSSdZ+58dhdRyNETgmndOMbI0E4uMw9INJVwLvqNK91/AIeFuISuEFWuTITPCoH4VIGndyTaOUOA4U/yaixfin6VxnqdWGs7E2JDZtOwIQ==;24:lVvQv533m2FT08kdoUFP9YeA/0JlPTLgzbTqBtvPLAmkbBjIkw/Q9l4SU59I5yREE7umDm+FgDVzJA9Tzewp78sctjJMr4vmg3MnikgrDH0=;7:2sRw6/4J91zl8Z0/o4iKvNaOaUizSGK9RtgAO42ypEcu6K1iJI+WL3n1NZNuOTyngeLlILGMQ8N0fhJNf6GkSJ2JCwQyqwJ1r06N29DxvVssdVvW7m6fTfGGgR6S774QjGOne++T3w7dcejzGVnb31GCxxVQRdPgQFkAFOtpoNnFLdn32njW0hco5HqYaxu/oghXmkEWQQhs4sR0y16UGKSmXY5rBpZhbf915d2isuQ2BaCmTcc+ygFgm1igKQDI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0005; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:CS1PR84MB0005;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0005; x-forefront-prvs: 0049B3F387 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(189002)(377424004)(24454002)(199003)(189998001)(81166006)(81156014)(2501003)(122556002)(106356001)(8676002)(1730700003)(36756003)(68736007)(77096005)(2351001)(5002640100001)(8936002)(10400500002)(3660700001)(4326007)(7416002)(5660300001)(5640700001)(6116002)(7736002)(102836003)(3280700002)(3846002)(586003)(2906002)(66066001)(2900100001)(110136002)(97736004)(19580395003)(2950100001)(11100500001)(7846002)(305945005)(8666005)(54356999)(50986999)(76176999)(105586002)(106116001)(99286002)(92566002)(86362001)(101416001)(33646002)(87936001)(103116003)(15975445007);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR84MB0005;H:CS1PR84MB0005.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <444204165259F745936FF1BD624D64E6@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2016 21:32:32.6511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0005 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 base64 to 8bit by mail.home.local id u7TLWgmG025616 On Mon, 2016-08-29 at 23:48 +0300, Kirill A. Shutemov wrote: > On Mon, Aug 29, 2016 at 01:11:19PM -0600, Toshi Kani wrote: > > > > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page > > size.  This feature relies on both mmap virtual address and FS > > block (i.e. physical address) to be aligned by the pmd page size. > > Users can use mkfs options to specify FS to align block > > allocations. However, aligning mmap address requires code changes > > to existing applications for providing a pmd-aligned address to > > mmap(). > > > > For instance, fio with "ioengine=mmap" performs I/Os with mmap() > > [1]. It calls mmap() with a NULL address, which needs to be changed > > to provide a pmd-aligned address for testing with DAX pmd mappings. > > Changing all applications that call mmap() with NULL is > > undesirable. > > > > This patch-set extends filesystems to align an mmap address for > > a DAX file so that unmodified applications can use DAX pmd > > mappings. > > +Hugh > > Can we get it used for shmem/tmpfs too? > I don't think we should duplicate essentially the same functionality > in multiple places. Here is my brief analysis when I had looked at the Hugh's patch last time (before shmem_get_unmapped_area() was accepted). https://patchwork.kernel.org/patch/8916741/ Besides some differences in the logic, ex. shmem_get_unmapped_area() always calls current->mm->get_unmapped_area twice, yes, they basically provide the same functionality. I think one issue is that shmem_get_unmapped_area() checks with its static flag 'shmem_huge', and additinally deals with SHMEM_HUGE_DENY and SHMEM_HUGE_FORCE cases.  It also handles non-file case for !SHMEM_HUGE_FORCE. Thanks, -Toshi