[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9673ed3c-9e42-3d01-000b-b01cda9832ce@cn.fujitsu.com>
Date: Mon, 10 Aug 2020 16:15:50 +0800
From: Ruan Shiyang <ruansy.fnst@...fujitsu.com>
To: Matthew Wilcox <willy@...radead.org>
CC: <linux-kernel@...r.kernel.org>, <linux-xfs@...r.kernel.org>,
<linux-nvdimm@...ts.01.org>, <linux-mm@...ck.org>,
<linux-fsdevel@...r.kernel.org>, <darrick.wong@...cle.com>,
<dan.j.williams@...el.com>, <david@...morbit.com>, <hch@....de>,
<rgoldwyn@...e.de>, <qi.fuli@...itsu.com>, <y-goto@...itsu.com>
Subject: Re: [RFC PATCH 0/8] fsdax: introduce FS query interface to support
reflink
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.
>
>
Powered by blists - more mailing lists