[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <677ef37ec8d26_2aff429467@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 8 Jan 2025 13:51:58 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Andrew Morton <akpm@...ux-foundation.org>, Alistair Popple
<apopple@...dia.com>
CC: <dan.j.williams@...el.com>, <linux-mm@...ck.org>, <lina@...hilina.net>,
<zhang.lyra@...il.com>, <gerald.schaefer@...ux.ibm.com>,
<vishal.l.verma@...el.com>, <dave.jiang@...el.com>, <logang@...tatee.com>,
<bhelgaas@...gle.com>, <jack@...e.cz>, <jgg@...pe.ca>,
<catalin.marinas@....com>, <will@...nel.org>, <mpe@...erman.id.au>,
<npiggin@...il.com>, <dave.hansen@...ux.intel.com>, <ira.weiny@...el.com>,
<willy@...radead.org>, <djwong@...nel.org>, <tytso@....edu>,
<linmiaohe@...wei.com>, <david@...hat.com>, <peterx@...hat.com>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <linuxppc-dev@...ts.ozlabs.org>,
<nvdimm@...ts.linux.dev>, <linux-cxl@...r.kernel.org>,
<linux-fsdevel@...r.kernel.org>, <linux-ext4@...r.kernel.org>,
<linux-xfs@...r.kernel.org>, <jhubbard@...dia.com>, <hch@....de>,
<david@...morbit.com>
Subject: Re: [PATCH v5 00/25] fs/dax: Fix ZONE_DEVICE page reference counts
Andrew Morton wrote:
> On Tue, 7 Jan 2025 14:42:16 +1100 Alistair Popple <apopple@...dia.com> wrote:
>
> > Device and FS DAX pages have always maintained their own page
> > reference counts without following the normal rules for page reference
> > counting. In particular pages are considered free when the refcount
> > hits one rather than zero and refcounts are not added when mapping the
> > page.
> >
> > Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary
> > mechanism for allowing GUP to hold references on the page (see
> > get_dev_pagemap). However there doesn't seem to be any reason why FS
> > DAX pages need their own reference counting scheme.
> >
> > By treating the refcounts on these pages the same way as normal pages
> > we can remove a lot of special checks. In particular pXd_trans_huge()
> > becomes the same as pXd_leaf(), although I haven't made that change
> > here. It also frees up a valuable SW define PTE bit on architectures
> > that have devmap PTE bits defined.
> >
> > It also almost certainly allows further clean-up of the devmap managed
> > functions, but I have left that as a future improvment. It also
> > enables support for compound ZONE_DEVICE pages which is one of my
> > primary motivators for doing this work.
> >
>
> https://lkml.kernel.org/r/wysuus23bqmjtwkfu3zutqtmkse3ki3erf45x32yezlrl24qto@xlqt7qducyld
> made me expect merge/build/runtime issues, however this series merges
> and builds OK on mm-unstable. Did something change? What's the story
> here?
>
> Oh well, it built so I'll ship it!
So my plan is to review this latest set on top of -next as is and then
rebase (or ask Alistair to rebase) on a mainline tag so I can identify
the merge conflicts with -mm and communicate those to Linus.
I will double check that you have pulled these back out of mm-unstable
before doing that to avoid a double-commit conflicts in -next, but for
now exposure in mm-unstable is good to flush out issues.
Powered by blists - more mailing lists