Re: [PATCH] mm, thp: Do not queue fully unmapped pages for deferred split

[Michal Hocko]

On Mon 16-09-19 13:11:37, Vlastimil Babka wrote:
> On 9/16/19 12:36 PM, Michal Hocko wrote:
> > On Fri 13-09-19 12:18:49, Kirill A. Shutemov wrote:
> >> Adding fully unmapped pages into deferred split queue is not productive:
> >> these pages are about to be freed or they are pinned and cannot be split
> >> anyway.
> >> 
> >> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
> >> ---
> >>  mm/rmap.c | 14 ++++++++++----
> >>  1 file changed, 10 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/mm/rmap.c b/mm/rmap.c
> >> index 003377e24232..45388f1bf317 100644
> >> --- a/mm/rmap.c
> >> +++ b/mm/rmap.c
> >> @@ -1271,12 +1271,20 @@ static void page_remove_anon_compound_rmap(struct page *page)
> >>  	if (TestClearPageDoubleMap(page)) {
> >>  		/*
> >>  		 * Subpages can be mapped with PTEs too. Check how many of
> >> -		 * themi are still mapped.
> >> +		 * them are still mapped.
> >>  		 */
> >>  		for (i = 0, nr = 0; i < HPAGE_PMD_NR; i++) {
> >>  			if (atomic_add_negative(-1, &page[i]._mapcount))
> >>  				nr++;
> >>  		}
> >> +
> >> +		/*
> >> +		 * Queue the page for deferred split if at least one small
> >> +		 * page of the compound page is unmapped, but at least one
> >> +		 * small page is still mapped.
> >> +		 */
> >> +		if (nr && nr < HPAGE_PMD_NR)
> >> +			deferred_split_huge_page(page);
> > 
> > You've set nr to zero in the for loop so this cannot work AFAICS.
> 
> The for loop then does nr++ for each subpage that's still mapped?

I am blind obviously. Sorry about the noise. Then the patch looks
correct.
-- 
Michal Hocko
SUSE Labs