All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Liu <bob.liu@oracle.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <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 <linux-ext4@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	linux-nvdimm <linux-nvdimm@ml01.01.org>, X86 ML <x86@kernel.org>,
	XFS Developers <xfs@oss.sgi.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v6 2/7] dax: support dirty DAX entries in radix tree
Date: Thu, 31 Dec 2015 11:28:13 +0800	[thread overview]
Message-ID: <5684A0CD.9040005@oracle.com> (raw)
In-Reply-To: <CAPcyv4jAO-jJ3VCOJRCc7zrQULED362SdZ88dDgN+zfQQEsfsA@mail.gmail.com>


On 12/31/2015 04:39 AM, Dan Williams wrote:
> On Wed, Dec 30, 2015 at 12:02 AM, Bob Liu <bob.liu@oracle.com> wrote:
>> Hi Ross,
>>
>> On 12/24/2015 03:39 AM, 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.
>>
>> I may get it wrong, but there is "struct page" for persistent memory after
>> "[PATCH v4 00/18]get_user_pages() for dax pte and pmd mappings".
>> So why not just add "struct page" to radix tree directly just like normal page cache?
>>
>> Then we don't need to deal with any exceptional entries and special writeback.
> 
> That "struct page" is optional and fsync/msync needs to operate in its absence.
> 

Any special reason or scenario that "struct page" should not be enabled?
I didn't see any disadvantages if always enable "struct page" by force when using DAX model for pmem.
The benefits would be things can be more simple and less potential bugs because of smaller patches.

Happy New Year!
Bob

WARNING: multiple messages have this Message-ID (diff)
From: Bob Liu <bob.liu@oracle.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <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 <linux-ext4@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	linux-nvdimm <linux-nvdimm@ml01.01.org>, X86 ML <x86@kernel.org>,
	XFS Developers <xfs@oss.sgi.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v6 2/7] dax: support dirty DAX entries in radix tree
Date: Thu, 31 Dec 2015 11:28:13 +0800	[thread overview]
Message-ID: <5684A0CD.9040005@oracle.com> (raw)
In-Reply-To: <CAPcyv4jAO-jJ3VCOJRCc7zrQULED362SdZ88dDgN+zfQQEsfsA@mail.gmail.com>


On 12/31/2015 04:39 AM, Dan Williams wrote:
> On Wed, Dec 30, 2015 at 12:02 AM, Bob Liu <bob.liu@oracle.com> wrote:
>> Hi Ross,
>>
>> On 12/24/2015 03:39 AM, 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.
>>
>> I may get it wrong, but there is "struct page" for persistent memory after
>> "[PATCH v4 00/18]get_user_pages() for dax pte and pmd mappings".
>> So why not just add "struct page" to radix tree directly just like normal page cache?
>>
>> Then we don't need to deal with any exceptional entries and special writeback.
> 
> That "struct page" is optional and fsync/msync needs to operate in its absence.
> 

Any special reason or scenario that "struct page" should not be enabled?
I didn't see any disadvantages if always enable "struct page" by force when using DAX model for pmem.
The benefits would be things can be more simple and less potential bugs because of smaller patches.

Happy New Year!
Bob

--
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: Bob Liu <bob.liu@oracle.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <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 <linux-ext4@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	linux-nvdimm <linux-nvdimm@ml01.01.org>, X86 ML <x86@kernel.org>,
	XFS Developers <xfs@oss.sgi.com>,
	Andrew Morton <akpm@linux-foundation.org>,
Subject: Re: [PATCH v6 2/7] dax: support dirty DAX entries in radix tree
Date: Thu, 31 Dec 2015 11:28:13 +0800	[thread overview]
Message-ID: <5684A0CD.9040005@oracle.com> (raw)
In-Reply-To: <CAPcyv4jAO-jJ3VCOJRCc7zrQULED362SdZ88dDgN+zfQQEsfsA@mail.gmail.com>


On 12/31/2015 04:39 AM, Dan Williams wrote:
> On Wed, Dec 30, 2015 at 12:02 AM, Bob Liu <bob.liu@oracle.com> wrote:
>> Hi Ross,
>>
>> On 12/24/2015 03:39 AM, 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.
>>
>> I may get it wrong, but there is "struct page" for persistent memory after
>> "[PATCH v4 00/18]get_user_pages() for dax pte and pmd mappings".
>> So why not just add "struct page" to radix tree directly just like normal page cache?
>>
>> Then we don't need to deal with any exceptional entries and special writeback.
> 
> That "struct page" is optional and fsync/msync needs to operate in its absence.
> 

Any special reason or scenario that "struct page" should not be enabled?
I didn't see any disadvantages if always enable "struct page" by force when using DAX model for pmem.
The benefits would be things can be more simple and less potential bugs because of smaller patches.

Happy New Year!
Bob

--
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: Bob Liu <bob.liu@oracle.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-nvdimm <linux-nvdimm@ml01.01.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Linux MM <linux-mm@kvack.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jeff Layton <jlayton@poochiereds.net>, X86 ML <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	XFS Developers <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" <linux-kernel@vger.kernel.org>,
	Jan Kara <jack@suse.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v6 2/7] dax: support dirty DAX entries in radix tree
Date: Thu, 31 Dec 2015 11:28:13 +0800	[thread overview]
Message-ID: <5684A0CD.9040005@oracle.com> (raw)
In-Reply-To: <CAPcyv4jAO-jJ3VCOJRCc7zrQULED362SdZ88dDgN+zfQQEsfsA@mail.gmail.com>


On 12/31/2015 04:39 AM, Dan Williams wrote:
> On Wed, Dec 30, 2015 at 12:02 AM, Bob Liu <bob.liu@oracle.com> wrote:
>> Hi Ross,
>>
>> On 12/24/2015 03:39 AM, 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.
>>
>> I may get it wrong, but there is "struct page" for persistent memory after
>> "[PATCH v4 00/18]get_user_pages() for dax pte and pmd mappings".
>> So why not just add "struct page" to radix tree directly just like normal page cache?
>>
>> Then we don't need to deal with any exceptional entries and special writeback.
> 
> That "struct page" is optional and fsync/msync needs to operate in its absence.
> 

Any special reason or scenario that "struct page" should not be enabled?
I didn't see any disadvantages if always enable "struct page" by force when using DAX model for pmem.
The benefits would be things can be more simple and less potential bugs because of smaller patches.

Happy New Year!
Bob

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

  reply	other threads:[~2015-12-31  3:29 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-23 19:39 [PATCH v6 0/7] DAX fsync/msync support Ross Zwisler
2015-12-23 19:39 ` Ross Zwisler
2015-12-23 19:39 ` Ross Zwisler
2015-12-23 19:39 ` [PATCH v6 1/7] pmem: add wb_cache_pmem() to the PMEM API Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39 ` [PATCH v6 2/7] dax: support dirty DAX entries in radix tree Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-30  8:02   ` Bob Liu
2015-12-30  8:02     ` Bob Liu
2015-12-30  8:02     ` Bob Liu
2015-12-30 20:39     ` Dan Williams
2015-12-30 20:39       ` Dan Williams
2015-12-30 20:39       ` Dan Williams
2015-12-31  3:28       ` Bob Liu [this message]
2015-12-31  3:28         ` Bob Liu
2015-12-31  3:28         ` Bob Liu
2015-12-31  3:28         ` Bob Liu
2015-12-31 22:08         ` Dan Williams
2015-12-31 22:08           ` Dan Williams
2015-12-31 22:08           ` Dan Williams
2016-01-05  9:41   ` Jan Kara
2016-01-05  9:41     ` Jan Kara
2016-01-05  9:41     ` Jan Kara
2015-12-23 19:39 ` [PATCH v6 3/7] mm: add find_get_entries_tag() Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-24  0:28   ` Elliott, Robert (Persistent Memory)
2015-12-24  0:28     ` Elliott, Robert (Persistent Memory)
2015-12-24  0:28     ` Elliott, Robert (Persistent Memory)
2015-12-23 19:39 ` [PATCH v6 4/7] dax: add support for fsync/msync Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2016-01-03 18:13   ` Dan Williams
2016-01-03 18:13     ` Dan Williams
2016-01-03 18:13     ` Dan Williams
2016-01-05 11:13     ` Jan Kara
2016-01-05 11:13       ` Jan Kara
2016-01-05 11:13       ` Jan Kara
2016-01-05 15:50       ` Ross Zwisler
2016-01-05 15:50         ` Ross Zwisler
2016-01-05 15:50         ` Ross Zwisler
2016-01-05 15:50         ` Ross Zwisler
2016-01-06 18:10     ` Ross Zwisler
2016-01-06 18:10       ` Ross Zwisler
2016-01-06 18:10       ` Ross Zwisler
2016-01-06 18:10       ` Ross Zwisler
2016-01-05 11:13   ` Jan Kara
2016-01-05 11:13     ` Jan Kara
2016-01-05 11:13     ` Jan Kara
2016-01-05 17:12     ` Ross Zwisler
2016-01-05 17:12       ` Ross Zwisler
2016-01-05 17:12       ` Ross Zwisler
2016-01-05 17:12       ` Ross Zwisler
2016-01-05 17:20       ` Dan Williams
2016-01-05 17:20         ` Dan Williams
2016-01-05 17:20         ` Dan Williams
2016-01-05 17:20         ` Dan Williams
2016-01-05 18:14         ` Ross Zwisler
2016-01-05 18:14           ` Ross Zwisler
2016-01-05 18:14           ` Ross Zwisler
2016-01-05 18:22           ` Dan Williams
2016-01-05 18:22             ` Dan Williams
2016-01-05 18:22             ` Dan Williams
2016-01-05 18:22             ` Dan Williams
2015-12-23 19:39 ` [PATCH v6 5/7] ext2: call dax_pfn_mkwrite() for DAX fsync/msync Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39 ` [PATCH v6 6/7] ext4: " Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39 ` [PATCH v6 7/7] xfs: " Ross Zwisler
2015-12-23 19:39   ` Ross Zwisler
2015-12-23 19:39   ` 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=5684A0CD.9040005@oracle.com \
    --to=bob.liu@oracle.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=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@ml01.01.org \
    --cc=matthew.r.wilcox@intel.com \
    --cc=mingo@redhat.com \
    --cc=ross.zwisler@linux.intel.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.