lkml.org 
[lkml]   [2020]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH V2 01/12] fs/stat: Define DAX statx attribute
    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@intel.com> 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@intel.com wrote:
    > > > > > From: Ira Weiny <ira.weiny@intel.com>
    > > > > >

    [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@linux.ibm.com

    \
     
     \ /
      Last update: 2020-01-15 23:38    [W:5.472 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site