On Wed, Jul 26, 2017 at 1:11 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> 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.
