[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160908154931.73b8c075b8c8e4702f877bd7@linux-foundation.org>
Date: Thu, 8 Sep 2016 15:49:31 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: linux-nvdimm@...1.01.org, Toshi Kani <toshi.kani@....com>,
Matthew Wilcox <mawilcox@...rosoft.com>,
Nilesh Choudhury <nilesh.choudhury@...cle.com>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
linux-mm@...ck.org, dri-devel@...ts.freedesktop.org,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Kai Zhang <kai.ka.zhang@...cle.com>
Subject: Re: [PATCH v2 1/2] mm: fix cache mode of dax pmd mappings
On Wed, 07 Sep 2016 15:26:14 -0700 Dan Williams <dan.j.williams@...el.com> wrote:
> track_pfn_insert() in vmf_insert_pfn_pmd() 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).
>
> track_pfn_insert() relies on a previous call to reserve_memtype() to
> establish the expected page_cache_mode for the range. While memremap()
> arranges for reserve_memtype() to be called, devm_memremap_pages() does
> not. So, teach track_pfn_insert() and untrack_pfn() how to handle
> tracking without a vma, and arrange for devm_memremap_pages() to
> establish the write-back-cache reservation in the memtype tree.
Acked-by: Andrew Morton <akpm@...ux-foundation.org>
I'll grab [2/2].
Powered by blists - more mailing lists