On Tue, Sep 26, 2017 at 11:30:57AM -0600, Ross Zwisler wrote:
I agree that Christoph's idea about having the system
intelligently adjust to
use DAX based on performance information it gathers about the underlying
persistent memory (probably via the HMAT on x86_64 systems) is interesting,
but I think we're still a ways away from that.
So what are the missing blockers for a getting started?
FWIW, as my patches suggest and Jan observed I think that we should
users to turn on DAX by treating the inode flag and the mount flag as an 'or'
operation. i.e. you get DAX if either the mount option is specified or if the
inode flag is set, and you can continue to manipulate the per-inode flag as
you want regardless of the mount option. I think this provides maximum
flexibility of the mechanism to select DAX without enforcing policy.
IFF we stick to the dax flag that's the only workable way. The only
major issue I still see with that is that this allows unprivilegued
users to enable DAX on a any file they own / have write access to.
So there isn't really any way to effectively disable the DAX path
by the sysadmin.
Does it make sense at this point to just start a "dax" man
page that can
contain info about the mount options, inode flags, kernel config options, how
to get PMDs, etc? Or does this documentation need to be sprinkled around more
in existing man pages?
A dax manpage would be good.