From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756417AbcIHXhv (ORCPT ); Thu, 8 Sep 2016 19:37:51 -0400 Received: from mail-sn1nam02on0132.outbound.protection.outlook.com ([104.47.36.132]:62816 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755063AbcIHXhr (ORCPT ); Thu, 8 Sep 2016 19:37:47 -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/nTogkvaQaBgaSEAgAAMDQCAAAffAIAO/huAgAAv7YCAAJ/ZAA== Date: Thu, 8 Sep 2016 23:21:46 +0000 Message-ID: <1473376846.2092.69.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> <1472508000.1532.59.camel@hpe.com> <20160908105707.GA17331@node> <1473342519.2092.42.camel@hpe.com> In-Reply-To: <1473342519.2092.42.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.9] x-ms-office365-filtering-correlation-id: 69816744-c200-44b8-6ec4-08d3d83ee6f0 x-microsoft-exchange-diagnostics: 1;DF4PR84MB0010;6:ZFG2m5aaaFdreNb8IyxVKidWGUgtAetiTL5a0Aie29v/SVf0pHC0tzXDWFMN48n217IFQOCdsZxNQyQ7NMFgKP9tt4v8JUa5LwDNY5pZzpVzMOM4VVkvyrCzfRD+bYuHZFOmLjazS+iqnaN2S2GtcTf7jPw/MeHExyyMDC5uCV+M33zYWfGuRfH7jRPpSa3zJ45oaA/7kS/SySpiNau1piEwgveO6rgdY04t8vtFxazBw5/cMtYqZ7SoWUPYH4j/0TF4skZkDW/aqUnx/w/i6mX84hKs6MWl7oKiQdbL9ngizsqxEPpruBvNv2obD0eaShonQOgzuFTAq41y5YK7cw==;5:n3/FQ9Ou2VcciZL1nKEgLTy/CMCHzaAsIFwGfTwDZqU7hbh3fbaING27TYuJ/ClpuTfESjz+oqgLGv/MqbJLAGR6m1MfhyQBLlYBUI1XhSNd5/le4sXj/q+dYYeazsgws0oVtr8L7bUugTQzbb3OYg==;24:HH90ai2WXkJBu3q9zkgK3vtNBdAnnIQBXeU1Pa3OOjduOqeB6831/c0G9shVcemyJW++9qD3+I41fUfuPj2cB1tGp1JLvCcfG1hoxI5P9Kc=;7:RIGyVs6rJLv1uSBptqySiT4uKDcqc8si7Uq/VsqCJ0ZXc+LMAVA/+DZz4wTDdtgNVOooNwbT/+/qC4Ym3FUw7NXMioIR/AojU97Qs5wFzRKulUJtKDOra04hN59Ch33YH3itVgyYHlXKBs+TUdIgcrNQC4ylaLEawEeH29MuryyK2011/ygkw3lJyAM2BjGKbQzcOt3WE8GpnbN5isuPSHhCKiWZQT/uFc/kEUoJg7o1gRX/u0sO+fIqHwsinNez x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DF4PR84MB0010; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:DF4PR84MB0010;BCL:0;PCL:0;RULEID:;SRVR:DF4PR84MB0010; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(189002)(377424004)(199003)(24454002)(1730700003)(81166006)(101416001)(81156014)(8666005)(86362001)(3660700001)(87936001)(77096005)(106356001)(8676002)(105586002)(2351001)(2900100001)(54356999)(106116001)(50986999)(2950100001)(103116003)(76176999)(99286002)(3280700002)(7846002)(305945005)(8936002)(68736007)(122556002)(2501003)(66066001)(5640700001)(10400500002)(586003)(3846002)(110136002)(33646002)(102836003)(92566002)(97736004)(4326007)(11100500001)(93886004)(2906002)(5002640100001)(36756003)(189998001)(7416002)(6116002)(7736002)(5660300001);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0010;H:DF4PR84MB0010.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: <9350D07B6CBB5D478100CA51D35240A4@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2016 23:21:46.2239 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0010 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 u88Nc3O5028787 On Thu, 2016-09-08 at 07:48 -0600, Kani, Toshimitsu wrote: > On Thu, 2016-09-08 at 13:57 +0300, Kirill A. Shutemov wrote: > > > > On Mon, Aug 29, 2016 at 10:00:43PM +0000, Kani, Toshimitsu wrote:  : > > > > > > Looking further, these shmem_huge handlings only check pre- > > > conditions.  So, we should be able to make shmem_get_unmapped_are > > > a() 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, > > > > Do you have plan to submit such change? > > Yes, I will submit the change once I finish testing. I found a bug in the current code, and need some clarification.  The if-statement below is reverted. === diff --git a/mm/shmem.c b/mm/shmem.c index fd8b2b5..aec5b49 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1980,7 +1980,7 @@ unsigned long shmem_get_unmapped_area(struct file *file,                                 return addr;                         sb = shm_mnt->mnt_sb;                 } -               if (SHMEM_SB(sb)->huge != SHMEM_HUGE_NEVER) +               if (SHMEM_SB(sb)->huge == SHMEM_HUGE_NEVER)                         return addr;         } === Because of this bug, mounting tmpfs with "huge=never" enables huge page mappings, and "huge=always" or others disables it... The above simple change will change the default behavior, though.  When "huge=" option is not specified, SHMEM_SB(sb)->huge is set to zero, which is SHMEM_HUGE_NEVER.  Therefore, huge page mappings are enabled by default because of this bug. What's the intended default behavior of this feature? Thanks, -Toshi