[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <677ed3d45b9a3_2aff429479@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 8 Jan 2025 11:36:52 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Alistair Popple <apopple@...dia.com>, <akpm@...ux-foundation.org>,
<linux-mm@...ck.org>
CC: Alistair Popple <apopple@...dia.com>, <gerald.schaefer@...ux.ibm.com>,
<dan.j.williams@...el.com>, <jgg@...pe.ca>, <willy@...radead.org>,
<david@...hat.com>, <linux-kernel@...r.kernel.org>, <nvdimm@...ts.linux.dev>,
<linux-fsdevel@...r.kernel.org>, <linux-ext4@...r.kernel.org>,
<linux-xfs@...r.kernel.org>, <jhubbard@...dia.com>, <hch@....de>
Subject: Re: [RFC 0/4] mm: Remove pfn_t type
Alistair Popple wrote:
> Once my series[1] and Dan's cleanup[2] is merged all users of DAX will
> require a ZONE_DEVICE page which is properly refcounted. This means there
> is no longer any need for the PFN_DEV and PFN_MAP flags. Furthermore the
> PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used. It is
> therefore possible to remove the pfn_t type and replace any usage with raw
> pfns.
>
> The remaining users of PFN_DEV have simply passed this to
> vmf_insert_mixed(), however once my series is merged vmf_insert_mixed()
> doesn't need these flags anyway so those users can be trivially converted
> to using raw pfns.
>
> Note that this RFC has only been lightly build tested. Also the third patch
> probably needs further splitting up. I have pushed a tree with this, along
> with the prerequisite series, to
> https://github.com/apopple/linux/tree/pfn_t_cleanup
>
> [1] - https://lore.kernel.org/linux-mm/cover.425da7c4e76c2749d0ad1734f972b06114e02d52.1736221254.git-series.apopple@nvidia.com/
> [2] - https://lore.kernel.org/linux-mm/172721874675.497781.3277495908107141898.stgit@dwillia2-xfh.jf.intel.com/
For the series you can add:
Reviewed-by: Dan Williams <dan.j.williams@...el.com>
However, I expect that we need [2] at the top of your ZONE_DEVICE
series, because that conversion breaks FS_DAX_LIMITED. I see Andrew is
starting to pick this up so I'll go work that out with him.
Powered by blists - more mailing lists