From: Jason Gunthorpe <jgg@ziepe.ca> To: Joao Martins <joao.m.martins@oracle.com>, John Hubbard <jhubbard@nvidia.com>, Daniel Jordan <daniel.m.jordan@oracle.com> Cc: linux-mm@kvack.org, Dan Williams <dan.j.williams@intel.com>, Ira Weiny <ira.weiny@intel.com>, linux-nvdimm@lists.01.org, Matthew Wilcox <willy@infradead.org>, Jane Chu <jane.chu@oracle.com>, Muchun Song <songmuchun@bytedance.com>, Mike Kravetz <mike.kravetz@oracle.com>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH RFC 7/9] mm/gup: Decrement head page once for group of subpages Date: Tue, 8 Dec 2020 15:34:46 -0400 [thread overview] Message-ID: <20201208193446.GP5487@ziepe.ca> (raw) In-Reply-To: <20201208172901.17384-9-joao.m.martins@oracle.com> On Tue, Dec 08, 2020 at 05:28:59PM +0000, Joao Martins wrote: > Rather than decrementing the ref count one by one, we > walk the page array and checking which belong to the same > compound_head. Later on we decrement the calculated amount > of references in a single write to the head page. > > Signed-off-by: Joao Martins <joao.m.martins@oracle.com> > mm/gup.c | 41 ++++++++++++++++++++++++++++++++--------- > 1 file changed, 32 insertions(+), 9 deletions(-) > > diff --git a/mm/gup.c b/mm/gup.c > index 194e6981eb03..3a9a7229f418 100644 > +++ b/mm/gup.c > @@ -212,6 +212,18 @@ static bool __unpin_devmap_managed_user_page(struct page *page) > } > #endif /* CONFIG_DEV_PAGEMAP_OPS */ > > +static int record_refs(struct page **pages, int npages) > +{ > + struct page *head = compound_head(pages[0]); > + int refs = 1, index; > + > + for (index = 1; index < npages; index++, refs++) > + if (compound_head(pages[index]) != head) > + break; > + > + return refs; > +} > + > /** > * unpin_user_page() - release a dma-pinned page > * @page: pointer to page to be released > @@ -221,9 +233,9 @@ static bool __unpin_devmap_managed_user_page(struct page *page) > * that such pages can be separately tracked and uniquely handled. In > * particular, interactions with RDMA and filesystems need special handling. > */ > -void unpin_user_page(struct page *page) > +static void __unpin_user_page(struct page *page, int refs) Refs should be unsigned everywhere. I suggest using clear language 'page' here should always be a compound head called 'head' (or do we have another common variable name for this?) 'refs' is number of tail pages within the compound, so 'ntails' or something > { > - int refs = 1; > + int orig_refs = refs; > > page = compound_head(page); Caller should always do this > @@ -237,14 +249,19 @@ void unpin_user_page(struct page *page) > return; > > if (hpage_pincount_available(page)) > - hpage_pincount_sub(page, 1); > + hpage_pincount_sub(page, refs); > else > - refs = GUP_PIN_COUNTING_BIAS; > + refs *= GUP_PIN_COUNTING_BIAS; > > if (page_ref_sub_and_test(page, refs)) > __put_page(page); > > - mod_node_page_state(page_pgdat(page), NR_FOLL_PIN_RELEASED, 1); > + mod_node_page_state(page_pgdat(page), NR_FOLL_PIN_RELEASED, orig_refs); > +} And really this should be placed directly after try_grab_compound_head() and be given a similar name 'unpin_compound_head()'. Even better would be to split the FOLL_PIN part into a function so there was a clear logical pairing. And reviewing it like that I want to ask if this unpin sequence is in the right order.. I would expect it to be the reverse order of the get John? Is it safe to call mod_node_page_state() after releasing the refcount? This could race with hot-unplugging the struct pages so I think it is wrong. > +void unpin_user_page(struct page *page) > +{ > + __unpin_user_page(page, 1); Thus this is __unpin_user_page(compound_head(page), 1); > @@ -274,6 +291,7 @@ void unpin_user_pages_dirty_lock(struct page **pages, unsigned long npages, > bool make_dirty) > { > unsigned long index; > + int refs = 1; > > /* > * TODO: this can be optimized for huge pages: if a series of pages is > @@ -286,8 +304,9 @@ void unpin_user_pages_dirty_lock(struct page **pages, unsigned long npages, > return; > } > > - for (index = 0; index < npages; index++) { > + for (index = 0; index < npages; index += refs) { > struct page *page = compound_head(pages[index]); > + I think this is really hard to read, it should end up as some: for_each_compond_head(page_list, page_list_len, &head, &ntails) { if (!PageDirty(head)) set_page_dirty_lock(head, ntails); unpin_user_page(head, ntails); } And maybe you open code that iteration, but that basic idea to find a compound_head and ntails should be computational work performed. No reason not to fix set_page_dirty_lock() too while you are here. Also, this patch and the next can be completely independent of the rest of the series, it is valuable regardless of the other tricks. You can split them and progress them independently. .. and I was just talking about this with Daniel Jordan and some other people at your company :) Thanks, Jason
next prev parent reply other threads:[~2020-12-08 19:34 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-08 17:28 [PATCH RFC 0/9] mm, sparse-vmemmap: Introduce compound pagemaps Joao Martins 2020-12-08 17:28 ` [PATCH RFC 1/9] memremap: add ZONE_DEVICE support for compound pages Joao Martins 2020-12-09 5:59 ` John Hubbard 2020-12-09 6:33 ` Matthew Wilcox 2020-12-09 13:12 ` Joao Martins 2021-02-20 1:43 ` Dan Williams 2021-02-22 11:24 ` Joao Martins 2021-02-22 20:37 ` Dan Williams 2021-02-23 15:46 ` Joao Martins 2021-02-23 16:50 ` Dan Williams 2021-02-23 17:18 ` Joao Martins 2021-02-23 18:18 ` Dan Williams 2021-03-10 18:12 ` Joao Martins 2021-03-12 5:54 ` Dan Williams 2021-02-20 1:24 ` Dan Williams 2021-02-22 11:09 ` Joao Martins 2020-12-08 17:28 ` [PATCH RFC 2/9] sparse-vmemmap: Consolidate arguments in vmemmap section populate Joao Martins 2020-12-09 6:16 ` John Hubbard 2020-12-09 13:51 ` Joao Martins 2021-02-20 1:49 ` Dan Williams 2021-02-22 11:26 ` Joao Martins 2020-12-08 17:28 ` [PATCH RFC 3/9] sparse-vmemmap: Reuse vmemmap areas for a given mhp_params::align Joao Martins 2020-12-08 17:38 ` Joao Martins 2020-12-08 17:28 ` [PATCH RFC 3/9] sparse-vmemmap: Reuse vmemmap areas for a given page size Joao Martins 2021-02-20 3:34 ` Dan Williams 2021-02-22 11:42 ` Joao Martins 2021-02-22 22:40 ` Dan Williams 2021-02-23 15:46 ` Joao Martins 2020-12-08 17:28 ` [PATCH RFC 4/9] mm/page_alloc: Reuse tail struct pages for compound pagemaps Joao Martins 2021-02-20 6:17 ` Dan Williams 2021-02-22 12:01 ` Joao Martins 2020-12-08 17:28 ` [PATCH RFC 5/9] device-dax: Compound pagemap support Joao Martins 2020-12-08 17:28 ` [PATCH RFC 6/9] mm/gup: Grab head page refcount once for group of subpages Joao Martins 2020-12-08 19:49 ` Jason Gunthorpe 2020-12-09 11:05 ` Joao Martins 2020-12-09 15:15 ` Jason Gunthorpe 2020-12-09 16:02 ` Joao Martins 2020-12-09 16:24 ` Jason Gunthorpe 2020-12-09 17:27 ` Joao Martins 2020-12-09 18:14 ` Matthew Wilcox 2020-12-09 19:08 ` Jason Gunthorpe 2020-12-10 15:43 ` Joao Martins 2020-12-09 4:40 ` John Hubbard 2020-12-09 13:44 ` Joao Martins 2020-12-08 17:28 ` [PATCH RFC 7/9] mm/gup: Decrement head page " Joao Martins 2020-12-08 19:34 ` Jason Gunthorpe [this message] 2020-12-09 5:06 ` John Hubbard 2020-12-09 13:43 ` Jason Gunthorpe 2020-12-09 12:17 ` Joao Martins 2020-12-17 19:05 ` Joao Martins 2020-12-17 20:05 ` Jason Gunthorpe 2020-12-17 22:34 ` Joao Martins 2020-12-18 14:25 ` Jason Gunthorpe 2020-12-19 2:06 ` John Hubbard 2020-12-19 13:10 ` Joao Martins 2020-12-08 17:29 ` [PATCH RFC 8/9] RDMA/umem: batch page unpin in __ib_mem_release() Joao Martins 2020-12-08 19:29 ` Jason Gunthorpe 2020-12-09 10:59 ` Joao Martins 2020-12-19 13:15 ` Joao Martins 2020-12-09 5:18 ` John Hubbard 2020-12-08 17:29 ` [PATCH RFC 9/9] mm: Add follow_devmap_page() for devdax vmas Joao Martins 2020-12-08 19:57 ` Jason Gunthorpe 2020-12-09 8:05 ` Christoph Hellwig 2020-12-09 11:19 ` Joao Martins 2020-12-09 5:23 ` John Hubbard 2020-12-09 9:38 ` [PATCH RFC 0/9] mm, sparse-vmemmap: Introduce compound pagemaps David Hildenbrand 2020-12-09 9:52 ` [External] " Muchun Song 2021-02-20 1:18 ` Dan Williams 2021-02-22 11:06 ` Joao Martins 2021-02-22 14:32 ` Joao Martins 2021-02-23 16:28 ` Joao Martins 2021-02-23 16:44 ` Dan Williams 2021-02-23 17:15 ` Joao Martins 2021-02-23 18:15 ` Dan Williams 2021-02-23 18:54 ` Jason Gunthorpe 2021-02-23 22:48 ` Dan Williams 2021-02-23 23:07 ` Jason Gunthorpe 2021-02-24 0:14 ` Dan Williams 2021-02-24 1:00 ` Jason Gunthorpe 2021-02-24 1:32 ` Dan Williams
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201208193446.GP5487@ziepe.ca \ --to=jgg@ziepe.ca \ --cc=akpm@linux-foundation.org \ --cc=dan.j.williams@intel.com \ --cc=daniel.m.jordan@oracle.com \ --cc=ira.weiny@intel.com \ --cc=jane.chu@oracle.com \ --cc=jhubbard@nvidia.com \ --cc=joao.m.martins@oracle.com \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=mike.kravetz@oracle.com \ --cc=songmuchun@bytedance.com \ --cc=willy@infradead.org \ --subject='Re: [PATCH RFC 7/9] mm/gup: Decrement head page once for group of subpages' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).