From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756448AbcH2Wem (ORCPT ); Mon, 29 Aug 2016 18:34:42 -0400 Received: from mail-by2nam03on0090.outbound.protection.outlook.com ([104.47.42.90]:50176 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750840AbcH2Wek (ORCPT ); Mon, 29 Aug 2016 18:34:40 -0400 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/nTogkvaQaBgaSEAgAAMDQCAAAffAA== Date: Mon, 29 Aug 2016 22:00:43 +0000 Message-ID: <1472508000.1532.59.camel@hpe.com> References: <1472497881-9323-1-git-send-email-toshi.kani@hpe.com> <20160829204842.GA27286@node.shutemov.name> <1472506310.1532.47.camel@hpe.com> In-Reply-To: <1472506310.1532.47.camel@hpe.com> 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: 10072e39-0d94-4236-26a4-08d3d057ec4d x-microsoft-exchange-diagnostics: 1;CS1PR84MB0005;6:dDTabrIuYPpaV80pRcUjBQUhjmmiGx1z8uaaOQpEz2kT3aJDi8S9xPLOXkaYfhtaqgg6WplWJmR1we3iriUmJDuPFSMRgj0xNjwn1g+3V1+NEV3V7br6JLpv0PijcBQ0LcA4utmfRdvGAB5QBI9OHHXzvNZMBOSg4KdLr1ATFxWcrf/dVyeARUE31L5/uSVry4Zl5CUvdHZFkpY5I8kbUXZBeeN/11eL6sZjoayWuLHXpI9ncmTzRJ/Z579NVW8/dr0JEiBLh8Q45upTdWShZSwyOfIqE2Nwf2upUtvwUwYrBguDWvOQzSr963coGmwOs3uDZsaGsy3xDWmb1GIdZA==;5:KEflyvJvYR7XjxfTEV6pgKn9D3TOwlnBfu2/FO95D5ZyetRKlpdSa69rhKK+HV4ON5E7K1nOxV5jopyZAs2LmOn8mbSHiniHt6YIVMh3R8U6NVdbldAcMzPjFYDZ623BM9U7s3EYAcP/xGZYl27/dg==;24:kOXwBND3XFlxfpl0gzr4ebcJC+y6clNpHWB/jpas2RFQBx6r6gnoaR6RMGUT8HC+CEFYW4JVOga5vBTdiaxaSbUYgNZPALJArvdCzTm2ROM=;7:JX0Sv/IKrWXYipNOAwPgv1584HYWx0m/zZe1dwo+Purz31nQYA1urDnaVhCsCodijY6QFrOi+CGFZvG2t+jLpsWbPVihZcMs+fzo7r6kDzdc8MFgIm+foLMlfP/1oV0RlfZq+CV3nb60SJgouc5B7GPh1qdfppOaPdn3gJCDB3nkGWMGMdPkN4WQxZEhpMR8E+91b5tdaiT6HWyL2SgLDe8TLobdFGlzCD2uf64wnH2ls04b9izTFPUPvtYA/yb3 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)(377424004)(24454002)(199003)(189002)(11100500001)(7846002)(8666005)(305945005)(2950100001)(2900100001)(66066001)(19580395003)(97736004)(110136002)(103116003)(33646002)(87936001)(15975445007)(106116001)(105586002)(99286002)(54356999)(50986999)(76176999)(101416001)(86362001)(92566002)(77096005)(68736007)(2351001)(36756003)(5002640100001)(81166006)(2501003)(81156014)(189998001)(8676002)(1730700003)(106356001)(122556002)(102836003)(7736002)(3280700002)(3846002)(6116002)(5640700001)(2906002)(586003)(3660700001)(8936002)(10400500002)(7416002)(5660300001)(4326007);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR84MB0005;H:CS1PR84MB0005.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7A35FDC77690ED41A514F00658A38AA0@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2016 22:00:43.3333 (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 u7TMYlCJ025830 On Mon, 2016-08-29 at 15:31 -0600, Kani, Toshimitsu wrote: > 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. Looking further, these shmem_huge handlings only check pre-conditions.  So, we should be able to make shmem_get_unmapped_area() as a wrapper, which checks such shmem-specific conitions, and then call __thp_get_unmapped_area() for the actual work.  All DAX-specific checks are performed in thp_get_unmapped_area() as well.  We can make  __thp_get_unmapped_area() as a common function. I'd prefer to make such change as a separate item, but I can include it to this patch series if needed.  Thanks, -Toshi