[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66196d85f3a16_36222e29490@dwillia2-xfh.jf.intel.com.notmuch>
Date: Fri, 12 Apr 2024 10:21:10 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Alistair Popple <apopple@...dia.com>, <linux-mm@...ck.org>
CC: <david@...morbit.com>, <dan.j.williams@...el.com>, <jhubbard@...dia.com>,
<rcampbell@...dia.com>, <willy@...radead.org>, <jgg@...dia.com>,
<linux-fsdevel@...r.kernel.org>, <jack@...e.cz>, <djwong@...nel.org>,
<hch@....de>, <david@...hat.com>, <ruansy.fnst@...itsu.com>,
<nvdimm@...ts.linux.dev>, <linux-xfs@...r.kernel.org>,
<linux-ext4@...r.kernel.org>, <jglisse@...hat.com>, Alistair Popple
<apopple@...dia.com>
Subject: RE: [RFC 04/10] fs/dax: Don't track page mapping/index
Alistair Popple wrote:
> The page->mapping and page->index fields are normally used by the
> pagecache and rmap for looking up virtual mappings of pages. FS DAX
> implements it's own kind of page cache and rmap look ups so these
> fields are unnecessary. They are currently only used to detect
> error/warning conditions which should never occur.
>
> A future change will change the way shared mappings are detected by
> doing normal page reference counting instead, so remove the
> unnecessary checks.
Ignore my comment on patch3, I fumble fingered the reply, it was meant
to for this patch. I.e. that "future change" should just be present
before removing old logic.
Powered by blists - more mailing lists