Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp789543ybh; Mon, 13 Jul 2020 00:52:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPpH/NPQFQqbxZcHnpintF50PtB4DFWN/UE/Tg80F+bGdJqhWqt84Br0XLQ5CvPM1H4nRo X-Received: by 2002:a05:6402:180a:: with SMTP id g10mr79207699edy.152.1594626772626; Mon, 13 Jul 2020 00:52:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594626772; cv=none; d=google.com; s=arc-20160816; b=q3Xd35/gyXbca8/43lN8TyAqqZjN3AsGkieWl5xu/EG+2tHwAEC7VgRHLpzIcT7cQD yBqxBt+EiZRWBQbZlx6H3k44WuJT+rORGORz0VeAZL9oc3qaaUs0m5YVBWgkpfvuKybN NjUHxut74MUF4eqvrWejT9+6bwZPbcQNJLA/zj7nRlb9QzHgrOaWwl9gDRaOxrghp1Dy A1W4zd0fwslJu9/t+Ho9wCFEa/VWLMY3o6CEXTs94AjsBPfdGRKa8Khalv/ZYk6ZxPKG l0rxren7755Piv16wexE7bCdmKTsfCCP0kL/bUl6CLRdBIZq9AjWIKfH17ZUjvFGfvng 1dBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Km9UHFuMNm1h9ix3cdc4E0UUYXXB24auYM37BSZ5p3w=; b=sycH2IduxKPgx2qeU9xm26owXudEkR8mA7uxf4fdg306qbEs/HJgdZ6rse8sBfN0Ck KXZ9ZUZDPilJEXHuha/MY2AVYUWIs21SPvTpwg/HdxmpWuz5kOyCtS/wmFHXr7XAcjRm zMjXCqcorGJcQZg8Y7vVQhj5vche0Jwi/WLTgDKpM2oKcKCTvOI8M9gIq5hdUIRPgUpC nL+149aKUvKH6M/JV9SCGsruON9mjQILqJYNbDwnpQ8zlIg4OSv6BoAyJYZ2qcJZWRwX gaB0kecuonfPinXA6dyqrfvXPSMrcpDg9xVBlmN12UXos6ygDZNM0s9HEOBoL3u0iGnh aHww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h17si8808729ejd.655.2020.07.13.00.52.29; Mon, 13 Jul 2020 00:52:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726571AbgGMHwX (ORCPT + 99 others); Mon, 13 Jul 2020 03:52:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:45510 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725818AbgGMHwW (ORCPT ); Mon, 13 Jul 2020 03:52:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B2364ACE1; Mon, 13 Jul 2020 07:52:23 +0000 (UTC) Subject: Re: [PATCH v5 4/9] mm/migrate: clear __GFP_RECLAIM to make the migration callback consistent with regular THP allocations To: js1304@gmail.com, Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@lge.com, Christoph Hellwig , Roman Gushchin , Mike Kravetz , Naoya Horiguchi , Michal Hocko , Joonsoo Kim References: <1594622517-20681-1-git-send-email-iamjoonsoo.kim@lge.com> <1594622517-20681-5-git-send-email-iamjoonsoo.kim@lge.com> From: Vlastimil Babka Message-ID: <367ca602-1112-f87f-7d2a-b0a75cce7269@suse.cz> Date: Mon, 13 Jul 2020 09:52:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <1594622517-20681-5-git-send-email-iamjoonsoo.kim@lge.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/13/20 8:41 AM, js1304@gmail.com wrote: > From: Joonsoo Kim > > new_page_nodemask is a migration callback and it tries to use a common > gfp flags for the target page allocation whether it is a base page or a > THP. The later only adds GFP_TRANSHUGE to the given mask. This results > in the allocation being slightly more aggressive than necessary because > the resulting gfp mask will contain also __GFP_RECLAIM_KSWAPD. THP > allocations usually exclude this flag to reduce over eager background > reclaim during a high THP allocation load which has been seen during > large mmaps initialization. There is no indication that this is a > problem for migration as well but theoretically the same might happen > when migrating large mappings to a different node. Make the migration > callback consistent with regular THP allocations. > > Signed-off-by: Joonsoo Kim Acked-by: Vlastimil Babka Thanks! Typo below (I assume Andrew will fix it) > --- > mm/migrate.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/mm/migrate.c b/mm/migrate.c > index 3b3d918..1cfc965 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -1547,6 +1547,11 @@ struct page *new_page_nodemask(struct page *page, > } > > if (PageTransHuge(page)) { > + /* > + * clear __GFP_RECALIM to make the migration callback __GFP_RECLAIM > + * consistent with regular THP allocations. > + */ > + gfp_mask &= ~__GFP_RECLAIM; > gfp_mask |= GFP_TRANSHUGE; > order = HPAGE_PMD_ORDER; > } >