[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240412115352.GY5383@nvidia.com>
Date: Fri, 12 Apr 2024 08:53:52 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Alistair Popple <apopple@...dia.com>
Cc: Dan Williams <dan.j.williams@...el.com>, linux-mm@...ck.org,
david@...morbit.com, jhubbard@...dia.com, rcampbell@...dia.com,
willy@...radead.org, 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
Subject: Re: [RFC 00/10] fs/dax: Fix FS DAX page reference counts
On Fri, Apr 12, 2024 at 04:55:31PM +1000, Alistair Popple wrote:
> Ok, I think I found the dragons you were talking about earlier for
> device-dax. I completely broke that because as you've already pointed
> out pmd_trans_huge() won't filter out DAX pages. That's fine for FS DAX
> (because the pages are essentially normal pages now anyway), but we
> don't have a PMD equivalent of vm_normal_page() which leads to all sorts
> of issues for DEVDAX.
What about vm_normal_page() depends on the radix level ?
Doesn't DEVDAX memory have struct page too?
> So I will probably have to add something like that unless we only need
> to support large (pmd/pud) mappings of DEVDAX pages on systems with
> CONFIG_ARCH_HAS_PTE_SPECIAL in which case I guess we could just filter
> based on pte_special().
pte_special should only be used by memory without a struct page, is
that what DEVDAX is?
Jason
Powered by blists - more mailing lists