All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Dave Chinner <david@fromorbit.com>,
	Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.com>,
	Jeff Layton <jlayton@poochiereds.net>,
	Matthew Wilcox <willy@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org, x86@kernel.org,
	xfs@oss.sgi.com, Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v5 2/7] dax: support dirty DAX entries in radix tree
Date: Mon, 21 Dec 2015 10:45:34 -0700	[thread overview]
Message-ID: <20151221174534.GA4978@linux.intel.com> (raw)
In-Reply-To: <20151221171512.GA7030@quack.suse.cz>

On Mon, Dec 21, 2015 at 06:15:12PM +0100, Jan Kara wrote:
> On Fri 18-12-15 22:22:15, Ross Zwisler wrote:
> > Add support for tracking dirty DAX entries in the struct address_space
> > radix tree.  This tree is already used for dirty page writeback, and it
> > already supports the use of exceptional (non struct page*) entries.
> > 
> > In order to properly track dirty DAX pages we will insert new exceptional
> > entries into the radix tree that represent dirty DAX PTE or PMD pages.
> > These exceptional entries will also contain the writeback addresses for the
> > PTE or PMD faults that we can use at fsync/msync time.
> > 
> > There are currently two types of exceptional entries (shmem and shadow)
> > that can be placed into the radix tree, and this adds a third.  We rely on
> > the fact that only one type of exceptional entry can be found in a given
> > radix tree based on its usage.  This happens for free with DAX vs shmem but
> > we explicitly prevent shadow entries from being added to radix trees for
> > DAX mappings.
> > 
> > The only shadow entries that would be generated for DAX radix trees would
> > be to track zero page mappings that were created for holes.  These pages
> > would receive minimal benefit from having shadow entries, and the choice
> > to have only one type of exceptional entry in a given radix tree makes the
> > logic simpler both in clear_exceptional_entry() and in the rest of DAX.
> > 
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> 
> The patch looks good to me. Just one comment: When we have this exclusion
> between different types of exceptional entries, there is no real need to
> have separate counters of 'shadow' and 'dax' entries, is there? We can have
> one 'nrexceptional' counter and don't have to grow struct inode
> unnecessarily which would be really welcome since DAX isn't a mainstream
> feature. Could you please change the code? Thanks!

Sure, this sounds good.  Thanks!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Dave Chinner <david@fromorbit.com>,
	Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.com>,
	Jeff Layton <jlayton@poochiereds.net>,
	Matthew Wilcox <willy@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@ml01.01.org, x86@kernel.org,
	xfs@oss.sgi.com, Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v5 2/7] dax: support dirty DAX entries in radix tree
Date: Mon, 21 Dec 2015 10:45:34 -0700	[thread overview]
Message-ID: <20151221174534.GA4978@linux.intel.com> (raw)
In-Reply-To: <20151221171512.GA7030@quack.suse.cz>

On Mon, Dec 21, 2015 at 06:15:12PM +0100, Jan Kara wrote:
> On Fri 18-12-15 22:22:15, Ross Zwisler wrote:
> > Add support for tracking dirty DAX entries in the struct address_space
> > radix tree.  This tree is already used for dirty page writeback, and it
> > already supports the use of exceptional (non struct page*) entries.
> > 
> > In order to properly track dirty DAX pages we will insert new exceptional
> > entries into the radix tree that represent dirty DAX PTE or PMD pages.
> > These exceptional entries will also contain the writeback addresses for the
> > PTE or PMD faults that we can use at fsync/msync time.
> > 
> > There are currently two types of exceptional entries (shmem and shadow)
> > that can be placed into the radix tree, and this adds a third.  We rely on
> > the fact that only one type of exceptional entry can be found in a given
> > radix tree based on its usage.  This happens for free with DAX vs shmem but
> > we explicitly prevent shadow entries from being added to radix trees for
> > DAX mappings.
> > 
> > The only shadow entries that would be generated for DAX radix trees would
> > be to track zero page mappings that were created for holes.  These pages
> > would receive minimal benefit from having shadow entries, and the choice
> > to have only one type of exceptional entry in a given radix tree makes the
> > logic simpler both in clear_exceptional_entry() and in the rest of DAX.
> > 
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> 
> The patch looks good to me. Just one comment: When we have this exclusion
> between different types of exceptional entries, there is no real need to
> have separate counters of 'shadow' and 'dax' entries, is there? We can have
> one 'nrexceptional' counter and don't have to grow struct inode
> unnecessarily which would be really welcome since DAX isn't a mainstream
> feature. Could you please change the code? Thanks!

Sure, this sounds good.  Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	linux-mm@kvack.org, Andreas Dilger <adilger.kernel@dilger.ca>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jeff Layton <jlayton@poochiereds.net>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-nvdimm@lists.01.org, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-ext4@vger.kernel.org, xfs@oss.sgi.com,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Theodore Ts'o <tytso@mit.edu>,
	linux-kernel@vger.kernel.org, Jan Kara <jack@suse.com>,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v5 2/7] dax: support dirty DAX entries in radix tree
Date: Mon, 21 Dec 2015 10:45:34 -0700	[thread overview]
Message-ID: <20151221174534.GA4978@linux.intel.com> (raw)
In-Reply-To: <20151221171512.GA7030@quack.suse.cz>

On Mon, Dec 21, 2015 at 06:15:12PM +0100, Jan Kara wrote:
> On Fri 18-12-15 22:22:15, Ross Zwisler wrote:
> > Add support for tracking dirty DAX entries in the struct address_space
> > radix tree.  This tree is already used for dirty page writeback, and it
> > already supports the use of exceptional (non struct page*) entries.
> > 
> > In order to properly track dirty DAX pages we will insert new exceptional
> > entries into the radix tree that represent dirty DAX PTE or PMD pages.
> > These exceptional entries will also contain the writeback addresses for the
> > PTE or PMD faults that we can use at fsync/msync time.
> > 
> > There are currently two types of exceptional entries (shmem and shadow)
> > that can be placed into the radix tree, and this adds a third.  We rely on
> > the fact that only one type of exceptional entry can be found in a given
> > radix tree based on its usage.  This happens for free with DAX vs shmem but
> > we explicitly prevent shadow entries from being added to radix trees for
> > DAX mappings.
> > 
> > The only shadow entries that would be generated for DAX radix trees would
> > be to track zero page mappings that were created for holes.  These pages
> > would receive minimal benefit from having shadow entries, and the choice
> > to have only one type of exceptional entry in a given radix tree makes the
> > logic simpler both in clear_exceptional_entry() and in the rest of DAX.
> > 
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> 
> The patch looks good to me. Just one comment: When we have this exclusion
> between different types of exceptional entries, there is no real need to
> have separate counters of 'shadow' and 'dax' entries, is there? We can have
> one 'nrexceptional' counter and don't have to grow struct inode
> unnecessarily which would be really welcome since DAX isn't a mainstream
> feature. Could you please change the code? Thanks!

Sure, this sounds good.  Thanks!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-12-21 17:45 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-19  5:22 [PATCH v5 0/7] DAX fsync/msync support Ross Zwisler
2015-12-19  5:22 ` Ross Zwisler
2015-12-19  5:22 ` Ross Zwisler
2015-12-19  5:22 ` [PATCH v5 1/7] pmem: add wb_cache_pmem() to the PMEM API Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-22 22:44   ` Andrew Morton
2015-12-22 22:44     ` Andrew Morton
2015-12-22 22:44     ` Andrew Morton
2015-12-23  0:00     ` Ross Zwisler
2015-12-23  0:00       ` Ross Zwisler
2015-12-23  0:00       ` Ross Zwisler
2015-12-19  5:22 ` [PATCH v5 2/7] dax: support dirty DAX entries in radix tree Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-21 17:15   ` Jan Kara
2015-12-21 17:15     ` Jan Kara
2015-12-21 17:15     ` Jan Kara
2015-12-21 17:15     ` Jan Kara
2015-12-21 17:45     ` Ross Zwisler [this message]
2015-12-21 17:45       ` Ross Zwisler
2015-12-21 17:45       ` Ross Zwisler
2015-12-22 22:46   ` Andrew Morton
2015-12-22 22:46     ` Andrew Morton
2015-12-22 22:46     ` Andrew Morton
2015-12-23  0:16     ` Ross Zwisler
2015-12-23  0:16       ` Ross Zwisler
2015-12-23  0:16       ` Ross Zwisler
2015-12-19  5:22 ` [PATCH v5 3/7] mm: add find_get_entries_tag() Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-22 22:46   ` Andrew Morton
2015-12-22 22:46     ` Andrew Morton
2015-12-22 22:46     ` Andrew Morton
2015-12-19  5:22 ` [PATCH v5 4/7] dax: add support for fsync/sync Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-19 18:37   ` Dan Williams
2015-12-19 18:37     ` Dan Williams
2015-12-19 18:37     ` Dan Williams
2015-12-21 17:05     ` Ross Zwisler
2015-12-21 17:05       ` Ross Zwisler
2015-12-21 17:05       ` Ross Zwisler
2015-12-21 17:49       ` Dan Williams
2015-12-21 17:49         ` Dan Williams
2015-12-21 17:49         ` Dan Williams
2015-12-21 17:49         ` Dan Williams
2015-12-21 19:27       ` Dan Williams
2015-12-21 19:27         ` Dan Williams
2015-12-21 19:27         ` Dan Williams
2015-12-21 19:27         ` Dan Williams
2015-12-22 22:46   ` Andrew Morton
2015-12-22 22:46     ` Andrew Morton
2015-12-22 22:46     ` Andrew Morton
2015-12-22 23:51     ` Ross Zwisler
2015-12-22 23:51       ` Ross Zwisler
2015-12-22 23:51       ` Ross Zwisler
2015-12-19  5:22 ` [PATCH v5 5/7] ext2: call dax_pfn_mkwrite() for DAX fsync/msync Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-21 17:32   ` Jan Kara
2015-12-21 17:32     ` Jan Kara
2015-12-21 17:32     ` Jan Kara
2015-12-21 17:32     ` Jan Kara
2015-12-19  5:22 ` [PATCH v5 6/7] ext4: " Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-21 17:32   ` Jan Kara
2015-12-21 17:32     ` Jan Kara
2015-12-21 17:32     ` Jan Kara
2015-12-19  5:22 ` [PATCH v5 7/7] xfs: " Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler
2015-12-19  5:22   ` Ross Zwisler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151221174534.GA4978@linux.intel.com \
    --to=ross.zwisler@linux.intel.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=bfields@fieldses.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@fromorbit.com \
    --cc=hpa@zytor.com \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=jlayton@poochiereds.net \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=matthew.r.wilcox@intel.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@linux.intel.com \
    --cc=x86@kernel.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.