On Wed, Jan 15, 2020 at 12:10:50PM -0800, Dan Williams wrote:
> On Wed, Jan 15, 2020 at 11:45 AM Ira Weiny <ira.weiny@xxxxxxxxx> wrote:
> >
> > On Wed, Jan 15, 2020 at 09:38:34AM -0800, Darrick J. Wong wrote:
> > > On Wed, Jan 15, 2020 at 12:37:15PM +0100, Jan Kara wrote:
> > > > On Fri 10-01-20 11:29:31, ira.weiny@xxxxxxxxx wrote:
> > > > > From: Ira Weiny <ira.weiny@xxxxxxxxx>
> > > > >
[snip]
> > Ok I changed a couple of things as well. How does this sound?
> >
> >
> > STATX_ATTR_DAX
> >
> > DAX (cpu direct access) is a file mode that attempts to minimize
>
> s/mode/state/?
DOH! yes state... ;-)
>
> > software cache effects for both I/O and memory mappings of this
> > file. It requires a block device and file system which have
> > been configured to support DAX.
>
> It may not require a block device in the future.
Ok:
"It requires a file system which has been configured to support DAX." ?
I'm trying to separate the user of the individual STATX DAX flag from the Admin
details of configuring the file system and/or devices which supports it.
Also, I just realized that we should follow the format of the other STATX_*
attributes. They all read something like "the file is..."
So I'm adding that text as well.
>
> >
> > DAX generally assumes all accesses are via cpu load / store
> > instructions which can minimize overhead for small accesses, but
> > may adversely affect cpu utilization for large transfers.
> >
> > File I/O is done directly to/from user-space buffers and memory
> > mapped I/O may be performed with direct memory mappings that
> > bypass kernel page cache.
> >
> > While the DAX property tends to result in data being transferred
> > synchronously, it does not give the same guarantees of
> > synchronous I/O where data and the necessary metadata are
>
> Maybe use "O_SYNC I/O" explicitly to further differentiate the 2
> meanings of "synchronous" in this sentence?
Done.
>
> > transferred together.
> >
> > A DAX file may support being mapped with the MAP_SYNC flag,
> > which enables a program to use CPU cache flush operations to
>
> s/operations/instructions/
Done.
>
> > persist CPU store operations without an explicit fsync(2). See
> > mmap(2) for more information.
>
> I think this also wants a reference to the Linux interpretation of
> platform "persistence domains" we were discussing that here [1], but
> maybe it should be part of a "pmem" manpage that can be referenced
> from this man page.
Sure, but for now I think referencing mmap for details on MAP_SYNC works.
I suspect that we may have some word smithing once I get this series in and we
submit a change to the statx man page itself. Can I move forward with the
following for this patch?
<quote>
STATX_ATTR_DAX
The file is in the DAX (cpu direct access) state. DAX state
attempts to minimize software cache effects for both I/O and
memory mappings of this file. It requires a file system which
has been configured to support DAX.
DAX generally assumes all accesses are via cpu load / store
instructions which can minimize overhead for small accesses, but
may adversely affect cpu utilization for large transfers.
File I/O is done directly to/from user-space buffers and memory
mapped I/O may be performed with direct memory mappings that
bypass kernel page cache.
While the DAX property tends to result in data being transferred
synchronously, it does not give the same guarantees of
synchronous I/O where data and the necessary metadata are
transferred together.
A DAX file may support being mapped with the MAP_SYNC flag,
which enables a program to use CPU cache flush instructions to
persist CPU store operations without an explicit fsync(2). See
mmap(2) for more information.
</quote>
Ira
>
> [1]: http://lore.kernel.org/r/20200108064905.170394-1-aneesh.kumar@xxxxxxxxxxxxx
