From: Ruan Shiyang <ruansy.fnst@cn.fujitsu.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, darrick.wong@oracle.com,
david@fromorbit.com, hch@lst.de, rgoldwyn@suse.de,
qi.fuli@fujitsu.com, y-goto@fujitsu.com
Subject: Re: [RFC PATCH 0/8] fsdax: introduce FS query interface to support reflink
Date: Mon, 10 Aug 2020 16:15:50 +0800 [thread overview]
Message-ID: <9673ed3c-9e42-3d01-000b-b01cda9832ce@cn.fujitsu.com> (raw)
In-Reply-To: <20200807133857.GC17456@casper.infradead.org>
On 2020/8/7 下午9:38, Matthew Wilcox wrote:
> On Fri, Aug 07, 2020 at 09:13:28PM +0800, Shiyang Ruan wrote:
>> This patchset is a try to resolve the problem of tracking shared page
>> for fsdax.
>>
>> Instead of per-page tracking method, this patchset introduces a query
>> interface: get_shared_files(), which is implemented by each FS, to
>> obtain the owners of a shared page. It returns an owner list of this
>> shared page. Then, the memory-failure() iterates the list to be able
>> to notify each process using files that sharing this page.
>>
>> The design of the tracking method is as follow:
>> 1. dax_assocaite_entry() associates the owner's info to this page
>
> I think that's the first problem with this design. dax_associate_entry is
> a horrendous idea which needs to be ripped out, not made more important.
> It's all part of the general problem of trying to do something on a
> per-page basis instead of per-extent basis.
>
The memory-failure needs to track owners info from a dax page, so I
should associate the owner with this page. In this version, I associate
the block device to the dax page, so that the memory-failure is able to
iterate the owners by the query interface provided by filesystem.
--
Thanks,
Ruan Shiyang.
>
>
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Ruan Shiyang <ruansy.fnst@cn.fujitsu.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-xfs@vger.kernel.org>,
<linux-nvdimm@lists.01.org>, <linux-mm@kvack.org>,
<linux-fsdevel@vger.kernel.org>, <darrick.wong@oracle.com>,
<dan.j.williams@intel.com>, <david@fromorbit.com>, <hch@lst.de>,
<rgoldwyn@suse.de>, <qi.fuli@fujitsu.com>, <y-goto@fujitsu.com>
Subject: Re: [RFC PATCH 0/8] fsdax: introduce FS query interface to support reflink
Date: Mon, 10 Aug 2020 16:15:50 +0800 [thread overview]
Message-ID: <9673ed3c-9e42-3d01-000b-b01cda9832ce@cn.fujitsu.com> (raw)
In-Reply-To: <20200807133857.GC17456@casper.infradead.org>
On 2020/8/7 下午9:38, Matthew Wilcox wrote:
> On Fri, Aug 07, 2020 at 09:13:28PM +0800, Shiyang Ruan wrote:
>> This patchset is a try to resolve the problem of tracking shared page
>> for fsdax.
>>
>> Instead of per-page tracking method, this patchset introduces a query
>> interface: get_shared_files(), which is implemented by each FS, to
>> obtain the owners of a shared page. It returns an owner list of this
>> shared page. Then, the memory-failure() iterates the list to be able
>> to notify each process using files that sharing this page.
>>
>> The design of the tracking method is as follow:
>> 1. dax_assocaite_entry() associates the owner's info to this page
>
> I think that's the first problem with this design. dax_associate_entry is
> a horrendous idea which needs to be ripped out, not made more important.
> It's all part of the general problem of trying to do something on a
> per-page basis instead of per-extent basis.
>
The memory-failure needs to track owners info from a dax page, so I
should associate the owner with this page. In this version, I associate
the block device to the dax page, so that the memory-failure is able to
iterate the owners by the query interface provided by filesystem.
--
Thanks,
Ruan Shiyang.
>
>
next prev parent reply other threads:[~2020-08-10 8:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 13:13 [RFC PATCH 0/8] fsdax: introduce FS query interface to support reflink Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 13:13 ` [RFC PATCH 1/8] fs: introduce get_shared_files() for dax&reflink Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 16:15 ` Darrick J. Wong
2020-08-07 16:15 ` Darrick J. Wong
2020-08-10 8:07 ` Ruan Shiyang
2020-08-10 8:07 ` Ruan Shiyang
2020-08-07 13:13 ` [RFC PATCH 2/8] fsdax, mm: track files sharing dax page for memory-failure Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 13:13 ` [RFC PATCH 3/8] fsdax: introduce dax_copy_edges() for COW Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 13:13 ` [RFC PATCH 4/8] fsdax: copy data before write Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 13:13 ` [RFC PATCH 5/8] fsdax: replace mmap entry in case of CoW Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 13:13 ` [RFC PATCH 6/8] fsdax: dedup file range to use a compare function Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 13:13 ` [RFC PATCH 7/8] fs/xfs: handle CoW for fsdax write() path Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 13:13 ` [RFC PATCH 8/8] fs/xfs: support dedupe for fsdax Shiyang Ruan
2020-08-07 13:13 ` Shiyang Ruan
2020-08-07 15:38 ` kernel test robot
2020-08-07 15:54 ` kernel test robot
2020-08-07 13:38 ` [RFC PATCH 0/8] fsdax: introduce FS query interface to support reflink Matthew Wilcox
2020-08-07 13:38 ` Matthew Wilcox
2020-08-10 8:15 ` Ruan Shiyang [this message]
2020-08-10 8:15 ` Ruan Shiyang
2020-08-10 11:16 ` Matthew Wilcox
2020-08-10 11:16 ` Matthew Wilcox
2020-08-10 21:10 ` Dave Chinner
2020-08-10 21:10 ` Dave Chinner
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=9673ed3c-9e42-3d01-000b-b01cda9832ce@cn.fujitsu.com \
--to=ruansy.fnst@cn.fujitsu.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.kernel.org \
--cc=qi.fuli@fujitsu.com \
--cc=rgoldwyn@suse.de \
--cc=willy@infradead.org \
--cc=y-goto@fujitsu.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.