[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4iNP0qxL5vToffBivkQWyUquD7HrgNmvYXQW9ejhFrAmA@mail.gmail.com>
Date: Wed, 26 Jul 2017 10:11:08 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: "linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-f2fs-devel@...ts.sourceforge.net,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Jaegeuk Kim <jaegeuk@...nel.org>,
sunqiuyang <sunqiuyang@...wei.com>
Subject: Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Wed, Jul 26, 2017 at 10:01 AM, Christoph Hellwig <hch@...radead.org> wrote:
> On Wed, Jul 26, 2017 at 09:53:07AM -0700, Dan Williams wrote:
>> It allows for opt-in for applications, or administrators of those
>> applications, that know the type of access.
>
> That's BS. We need to provide the best possible way to access the
> media to an application. And whether that's DAX or the page cache
> is an implementation detail that should not matter to the application.
>
> Which doesn't mean there shouldn't be ways to override the default
> that the kernel chose based on hardware details, but it's certainly
> not something for the application to hardcode, but something for
> the adminstrator to decide.
Until HMAT came along we had no data in the kernel how to pick a sane
default, but we could now very easily make a "if pmem performance <
dram, disable dax by default" policy in the kernel.
The question for this patch is do we want to add yet another
filesystem that adds "-o dax" or require use of per-inode flags to
enable dax.
Powered by blists - more mailing lists