From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757074AbcIGTjW (ORCPT ); Wed, 7 Sep 2016 15:39:22 -0400 Received: from mail-co1nam03on0104.outbound.protection.outlook.com ([104.47.40.104]:15978 "EHLO NAM03-CO1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754595AbcIGTjV (ORCPT ); Wed, 7 Sep 2016 15:39:21 -0400 From: "Kani, Toshimitsu" To: "dan.j.williams@intel.com" , "akpm@linux-foundation.org" CC: "linux-kernel@vger.kernel.org" , "kirill.shutemov@linux.intel.com" , "linux-nvdimm@ml01.01.org" , "linux-mm@kvack.org" , "stable@vger.kernel.org" , "mawilcox@microsoft.com" , "kai.ka.zhang@oracle.com" , "nilesh.choudhury@oracle.com" , "ross.zwisler@linux.intel.com" Subject: Re: [PATCH 4/5] mm: fix cache mode of dax pmd mappings Thread-Topic: [PATCH 4/5] mm: fix cache mode of dax pmd mappings Thread-Index: AQHSCF8no97Qdp0rykOwa0DAxYqgJ6Bs5sMAgAAaTICAAWz6gA== Date: Wed, 7 Sep 2016 19:39:19 +0000 Message-ID: <1473277101.2092.39.camel@hpe.com> References: <147318056046.30325.5100892122988191500.stgit@dwillia2-desk3.amr.corp.intel.com> <147318058165.30325.16762406881120129093.stgit@dwillia2-desk3.amr.corp.intel.com> <20160906131756.6b6c6315b7dfba3a9d5f233a@linux-foundation.org> In-Reply-To: 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: 3db913ca-f5fe-45d8-1dea-08d3d756a926 x-microsoft-exchange-diagnostics: 1;CS1PR84MB0006;6:XeQCYG9lMsKLVxEw44rg99zsaGjml9V2vG9206Sqy7jltYkV3FS4GatjsKxXQMCun/oNm17cEgochF+8cJRtxatD+M2WBN8305DbivcbBsQNWHRYDno9qtZQ8w+HXE55pmSZq1/KD6hfr/j9lKN5iMQZKMaaZsKDTMux+b5kmPL7zOwbF2DK1klG2FDfcBVbhEEJ8E6VenEljP8pNIUBCqqGk3YISq8dXyaeEKFxrqRRDvYZHXkMEzU+FBWCstesywTtppUtqajGGvgSdrxoCSPth0HlFxesVF/z0LVqMWAS/hDLcP20R4MWgw9soSjB6lFUaSAbCXXM/FH6RpC1og==;5:uRv3YFWNVpeuW+FjhFElwy4sS+BhxZgofT1D2SxIwvmcqIvBPdNsdHQjYazxZ4R3tbn9/bIzVKHFlf9lyFtnRZ8bZYnRnFFlPd5oLJyTskMZ/PKvnJPYVZOL3qEkrFV4kpogabJOk6uNv4z93eE1Xw==;24:O5habDuejI0wcRevqVl3CNpKLzGaX0cVLkBe1+L5njCzZn3UeNZfzXqkHh6HfKV8MJ+LZEqc+pcJddxmt7/ocbMBEefcuveOUhFMX0ExcLo=;7:czlyTtkewvMHsV22I/bhIX5pZpUtbnu41ZOCtOUhbTfgfTmQBqM/2BuBqAee8JqG86TyNfEIrKJxFya300wkyu6rTWk6k64o1YwsmoUYhPPxyxkhP/nsAAipTfaARVp8+h4imiWsybpBYlyaqqVzcqcAO7ZfWd6LwjqE0ZYyS+eQ0PqxO2RAq4cNKXCmWKauvcT6UX0fOKi4PqePbiUEAHHpotNwCeHXndsSMlYhsH66DBuDsw0IklKmYyxpJsnF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0006; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861)(9452136761055)(146099531331640)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);SRVR:CS1PR84MB0006;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0006; x-forefront-prvs: 0058ABBBC7 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(24454002)(199003)(377454003)(54534003)(377424004)(189002)(97736004)(2501003)(2900100001)(33646002)(77096005)(36756003)(99286002)(101416001)(7416002)(8936002)(68736007)(5001770100001)(189998001)(93886004)(87936001)(66066001)(54356999)(3660700001)(105586002)(122556002)(81166006)(81156014)(106116001)(2950100001)(3280700002)(5002640100001)(586003)(10400500002)(76176999)(5660300001)(103116003)(8676002)(50986999)(86362001)(3846002)(4326007)(6116002)(8666005)(102836003)(305945005)(106356001)(7846002)(19580405001)(2906002)(7736002)(92566002)(11100500001)(19580395003);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR84MB0006;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: MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2016 19:39:19.2627 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0006 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 u87JdSXt018532 On Tue, 2016-09-06 at 14:52 -0700, Dan Williams wrote: > On Tue, Sep 6, 2016 at 1:17 PM, Andrew Morton org> wrote: > > > > On Tue, 06 Sep 2016 09:49:41 -0700 Dan Williams > el.com> wrote: > > > > > > > > track_pfn_insert() is marking dax mappings as uncacheable. > > > > > > It is used to keep mappings attributes consistent across a > > > remapped range. However, since dax regions are never registered > > > via track_pfn_remap(), the caching mode lookup for dax pfns > > > always returns _PAGE_CACHE_MODE_UC.  We do not use > > > track_pfn_insert() in the dax-pte path, and we always want to use > > > the pgprot of the vma itself, so drop this call. > > > > > > Cc: Ross Zwisler > > > Cc: Matthew Wilcox > > > Cc: Kirill A. Shutemov > > > Cc: Andrew Morton > > > Cc: Nilesh Choudhury > > > Reported-by: Kai Zhang > > > Reported-by: Toshi Kani > > > Cc: > > > Signed-off-by: Dan Williams > > > > Changelog fails to explain the user-visible effects of the > > patch.  The stable maintainer(s) will look at this and wonder "ytf > > was I sent this". > > True, I'll change it to this: > > track_pfn_insert() is marking dax mappings as uncacheable rendering > them impractical for application usage.  DAX-pte mappings are cached > and the goal of establishing DAX-pmd mappings is to attain more > performance, not dramatically less (3 orders of magnitude). > > Deleting the call to track_pfn_insert() in vmf_insert_pfn_pmd() lets > the default pgprot (write-back cache enabled) from the vma be used > for the mapping which yields the expected performance improvement > over DAX-pte mappings. > > track_pfn_insert() is meant to keep the cache mode for a given range > synchronized across different users of remap_pfn_range() and > vm_insert_pfn_prot().  DAX uses neither of those mapping methods, and > the pmem driver is already marking its memory ranges as write-back > cache enabled.  So, removing the call to track_pfn_insert() leaves > the kernel no worse off than the current situation where a user could > map the range via /dev/mem with an incompatible cache mode compared > to the driver. I think devm_memremap_pages() should call reserve_memtype() on x86 to keep it consistent with devm_memremap() on this regard.  We may need an arch stub for reserve_memtype(), though.  Then, track_pfn_insert() should have no issue in this case. Thanks, -Toshi