Messages in this thread | | | Date | Tue, 12 Apr 2022 10:47:20 +0200 | Subject | Re: [PATCH v3 08/16] mm/rmap: drop "compound" parameter from page_add_new_anon_rmap() | From | Vlastimil Babka <> |
| |
On 3/29/22 18:04, David Hildenbrand wrote: > New anonymous pages are always mapped natively: only THP/khugepagd code
khugepaged ^
> maps a new compound anonymous page and passes "true". Otherwise, we're > just dealing with simple, non-compound pages. > > Let's give the interface clearer semantics and document these. > > Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Nit:
> --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -1182,19 +1182,22 @@ void page_add_anon_rmap(struct page *page, > } > > /** > - * page_add_new_anon_rmap - add pte mapping to a new anonymous page > + * page_add_new_anon_rmap - add mapping to a new anonymous page > * @page: the page to add the mapping to > * @vma: the vm area in which the mapping is added > * @address: the user virtual address mapped > - * @compound: charge the page as compound or small page > + * > + * If it's a compound page, it is accounted as a compound page. As the page > + * is new, it's assume to get mapped exclusively by a single process. > * > * Same as page_add_anon_rmap but must only be called on *new* pages. > * This means the inc-and-test can be bypassed. > * Page does not have to be locked. > */ > void page_add_new_anon_rmap(struct page *page, > - struct vm_area_struct *vma, unsigned long address, bool compound) > + struct vm_area_struct *vma, unsigned long address) > { > + const bool compound = PageCompound(page); > int nr = compound ? thp_nr_pages(page) : 1; > > VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
There's a VM_BUG_ON_PAGE(PageTransCompound(page), page); later in a !compound branch. Since compound is now determined by the same check, could be deleted.
| |