[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160912052703.GA1897@infradead.org>
Date: Sun, 11 Sep 2016 22:27:03 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Ross Zwisler <ross.zwisler@...ux.intel.com>,
Dan Williams <dan.j.williams@...el.com>,
Xiao Guangrong <guangrong.xiao@...ux.intel.com>,
Dave Hansen <dave.hansen@...el.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>, Gleb Natapov <gleb@...nel.org>,
mtosatti@...hat.com, KVM list <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Stefan Hajnoczi <stefanha@...hat.com>,
Yumei Huang <yuhuang@...hat.com>,
Linux MM <linux-mm@...ck.org>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in
/proc/self/smaps)
On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote:
> I think this goes back to our previous discussion about support for the PMEM
> programming model. Really I think what NVML needs isn't a way to tell if it
> is getting a DAX mapping, but whether it is getting a DAX mapping on a
> filesystem that fully supports the PMEM programming model. This of course is
> defined to be a filesystem where it can do all of its flushes from userspace
> safely and never call fsync/msync, and that allocations that happen in page
> faults will be synchronized to media before the page fault completes.
That's a an easy way to flag: you will never get that from a Linux
filesystem, period.
NVML folks really need to stop taking crack and dreaming this could
happen.
Powered by blists - more mailing lists