Message-ID: <87sewf48s6.fsf@nvdebian.thelocal>
Date: Fri, 12 Jul 2024 12:40:39 +1000
From: Alistair Popple <apopple@...dia.com>
To: Peter Xu <peterx@...hat.com>
Cc: dan.j.williams@...el.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,
 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-mm@...ck.org,
 linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
 jhubbard@...dia.com, hch@....de, david@...morbit.com, Alex Williamson
 <alex.williamson@...hat.com>
Subject: Re: [PATCH 11/13] huge_memory: Remove dead vmf_insert_pXd code


Peter Xu <peterx@...hat.com> writes:

> On Tue, Jul 09, 2024 at 02:07:31PM +1000, Alistair Popple wrote:
>> 
>> Peter Xu <peterx@...hat.com> writes:
>> 
>> > Hi, Alistair,
>> >
>> > On Thu, Jun 27, 2024 at 10:54:26AM +1000, Alistair Popple wrote:
>> >> Now that DAX is managing page reference counts the same as normal
>> >> pages there are no callers for vmf_insert_pXd functions so remove
>> >> them.
>> >> 
>> >> Signed-off-by: Alistair Popple <apopple@...dia.com>
>> >> ---
>> >>  include/linux/huge_mm.h |   2 +-
>> >>  mm/huge_memory.c        | 165 +-----------------------------------------
>> >>  2 files changed, 167 deletions(-)
>> >> 
>> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> >> index 9207d8e..0fb6bff 100644
>> >> --- a/include/linux/huge_mm.h
>> >> +++ b/include/linux/huge_mm.h
>> >> @@ -37,8 +37,6 @@ int change_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
>> >>  		    pmd_t *pmd, unsigned long addr, pgprot_t newprot,
>> >>  		    unsigned long cp_flags);
>> >>  
>> >> -vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write);
>> >> -vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write);
>> >>  vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write);
>> >>  vm_fault_t dax_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write);
>> >
>> > There's a plan to support huge pfnmaps in VFIO, which may still make good
>> > use of these functions.  I think it's fine to remove them but it may mean
>> > we'll need to add them back when supporting pfnmaps with no memmap.
>> 
>> I'm ok with that. If we need them back in future it shouldn't be too
>> hard to add them back again. I just couldn't find any callers of them
>> once DAX stopped using them and the usual policy is to remove unused
>> functions.
>
> True.  Currently the pmd/pud helpers are only used in dax.
>
>> 
>> > Is it still possible to make the old API generic to both service the new
>> > dax refcount plan, but at the meantime working for pfn injections when
>> > there's no page struct?
>> 
>> I don't think so - this new dax refcount plan relies on having a struct
>> page to take references on so I don't think it makes much sense to
>> combine it with something that doesn't have a struct page. It sounds
>> like the situation is the analogue of vm_insert_page()
>> vs. vmf_insert_pfn() - it's possible for both to exist but there's not
>> really anything that can be shared between the two APIs as one has a
>> page and the other is just a raw PFN.
>
> I still think most of the codes should be shared on e.g. most of sanity
> checks, pgtable injections, pgtable deposits (for pmd) and so on.

Yeah, it was mostly the BUG_ON's that weren't applicable once pXd_devmap
went away.

> To be explicit, I wonder whether something like below diff would be
> applicable on top of the patch "huge_memory: Allow mappings of PMD sized
> pages" in this series, which introduced dax_insert_pfn_pmd() for dax:
>
> $ diff origin new
> 1c1
> < vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write)
> ---
>> vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write)
> 55,58c55,60
> <       folio = page_folio(page);
> <       folio_get(folio);
> <       folio_add_file_rmap_pmd(folio, page, vma);
> <       add_mm_counter(mm, mm_counter_file(folio), HPAGE_PMD_NR);
> ---
>>         if (page) {
>>                 folio = page_folio(page);
>>                 folio_get(folio);
>>                 folio_add_file_rmap_pmd(folio, page, vma);
>>                 add_mm_counter(mm, mm_counter_file(folio), HPAGE_PMD_NR);
>>         }

We get the page from calling pfn_t_to_page(pfn). This is safe for the
DAX case but is it safe to use a page returned by this more generally?

>From an API perspective it would make more sense for the DAX code to
pass the page rather than the pfn. I didn't do that because device DAX
just had the PFN and this was DAX-specific code. But if we want to make
it generic I'd rather have callers pass the page in.

Of course that probably doesn't help you, because then the call would be
vmf_insert_page_pmd() rather than a raw pfn, but as you point out there
might be some common code we could share.

>
> As most of the rest look very similar to what pfn injections would need..
> and in the PoC of ours we're using vmf_insert_pfn_pmd/pud().

Do you have the PoC posted anywhere so I can get an understanding of how
this might be used?

> That also reminds me on whether it'll be easier to implement the new dax
> support for page struct on top of vmf_insert_pfn_pmd/pud, rather than
> removing the 1st then adding the new one.  Maybe it'll reduce code churns,
> and would that also make reviews easier?

Yeah, that's a good observation. I think it was just a quirk of how I
was developing this and also not caring about the PFN case so I'll see
what that looks like.

> It's also possible I missed something important so the old function must be
> removed.
>
> Thanks,

Powered by blists - more mailing lists