Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751141AbdGZU3Y (ORCPT ); Wed, 26 Jul 2017 16:29:24 -0400 Received: from mail-yw0-f179.google.com ([209.85.161.179]:36219 "EHLO mail-yw0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbdGZU3X (ORCPT ); Wed, 26 Jul 2017 16:29:23 -0400 MIME-Version: 1.0 In-Reply-To: <20170726201136.GA30039@infradead.org> References: <1500552639-18523-1-git-send-email-sunqiuyang@huawei.com> <20170726072634.GA4684@infradead.org> <20170726170147.GA31930@infradead.org> <20170726172011.GA30142@infradead.org> <20170726201136.GA30039@infradead.org> From: Dan Williams Date: Wed, 26 Jul 2017 13:29:21 -0700 Message-ID: Subject: Re: [PATCH v8 1/1] f2fs: dax: implement direct access To: Christoph Hellwig Cc: "linux-nvdimm@lists.01.org" , Linux Kernel Mailing List , linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel , Jaegeuk Kim , sunqiuyang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1496 Lines: 35 On Wed, Jul 26, 2017 at 1:11 PM, Christoph Hellwig wrote: > On Wed, Jul 26, 2017 at 12:16:11PM -0700, Dan Williams wrote: >> Silently turn on DAX if HMAT says its ok? > > Yes, absolutely. I want my system to do the right thing by default, > and if HMAT says bypassing the page cache is a clear advatange it > should be the default. > >> I think we would instead >> want a "-o autodax" for that case and then "-o dax" and "-o nodax" for >> the force cases. > > Why? > I'm worried about the case where HMAT says pmem >= dram performance, but dax semantics like disabling delayed allocation and dirty-cacheline tracking end up hurting performance, but I guess we can handle that on a case by case basis with targeted kernel optimizations. >> I think it's easier to administer than the dax mount option. If >> someone wants dax on only in a sub-tree they can set the flag on that >> parent directory and have a policy in dax filesystems that children >> inherit the dax policy from the parent. That seems a better >> administrative model than trying to get it all right globally at mount >> time. > > And why exactly? If DAX is faster for file a in directory X it will > be just as fast for a file b in directory Y. So I want the inode setting for the pmem < dram performance case where I know that access patterns of the application using file b in directory Y can still yield better performance without page cache. For example, the working set is larger than dram capacity.