[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <94D0CD8314A33A4D9D801C0FE68B40295BF38AA1@G9W0745.americas.hpqcorp.net>
Date: Fri, 22 Jan 2016 16:17:58 +0000
From: "Elliott, Robert (Persistent Memory)" <elliott@....com>
To: Ross Zwisler <ross.zwisler@...ux.intel.com>,
Jan Kara <jack@...e.cz>
CC: Andrew Morton <akpm@...ux-foundation.org>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
Dave Chinner <david@...morbit.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Jan Kara <jack@...e.com>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: RE: [PATCH v2 3/5] dax: improve documentation for fsync/msync
---
Robert Elliott, HPE Persistent Memory
> -----Original Message-----
> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@...ts.01.org] On Behalf Of
> Ross Zwisler
> Sent: Friday, January 22, 2016 9:58 AM
> To: Jan Kara <jack@...e.cz>
> Cc: Andrew Morton <akpm@...ux-foundation.org>; linux-nvdimm@...ts.01.org;
> Dave Chinner <david@...morbit.com>; linux-kernel@...r.kernel.org;
> Alexander Viro <viro@...iv.linux.org.uk>; Jan Kara <jack@...e.com>; linux-
> fsdevel@...r.kernel.org
> Subject: Re: [PATCH v2 3/5] dax: improve documentation for fsync/msync
>
> On Fri, Jan 22, 2016 at 04:01:29PM +0100, Jan Kara wrote:
> > On Thu 21-01-16 10:46:02, Ross Zwisler wrote:
...
> > > diff --git a/fs/dax.c b/fs/dax.c
> > > index d589113..55ae394 100644
> > > --- a/fs/dax.c
> > > +++ b/fs/dax.c
> > > @@ -350,6 +350,13 @@ static int dax_radix_entry(struct address_space
> *mapping, pgoff_t index,
> > >
> > > if (!pmd_entry || type == RADIX_DAX_PMD)
> > > goto dirty;
> > > +
> > > + /*
> > > + * We only insert dirty PMD entries into the radix tree. This
> > > + * means we don't need to worry about removing a dirty PTE
> > > + * entry and inserting a clean PMD entry, thus reducing the
> > > + * range we would flush with a follow-up fsync/msync call.
> > > + */
> >
> > May be acompany this with:
> >
> > WARN_ON(pmd_entry && !dirty);
> >
> > somewhere in dax_radix_entry()?
>
> Sure, I'll add one.
If this is something that could trigger due to I/O traffic, please
use WARN_ONCE rather than WARN_ON to avoid the risk of swamping
the serial output.
Powered by blists - more mailing lists