From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71B2FC17440 for ; Tue, 12 Nov 2019 08:04:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3FF7D21783 for ; Tue, 12 Nov 2019 08:04:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FF7D21783 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CB8DB6B0003; Tue, 12 Nov 2019 03:04:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C8E476B0005; Tue, 12 Nov 2019 03:04:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF3506B0006; Tue, 12 Nov 2019 03:04:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id AB29E6B0003 for ; Tue, 12 Nov 2019 03:04:05 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 57E3C181AEF09 for ; Tue, 12 Nov 2019 08:04:05 +0000 (UTC) X-FDA: 76146887250.03.lace36_7af659d02a82e X-HE-Tag: lace36_7af659d02a82e X-Filterd-Recvd-Size: 4013 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Nov 2019 08:04:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 33614B156; Tue, 12 Nov 2019 08:04:02 +0000 (UTC) Date: Tue, 12 Nov 2019 09:04:01 +0100 From: Michal Hocko To: Yang Shi Cc: mgorman@techsingularity.net, vbabka@suse.cz, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: migrate: handle freed page at the first place Message-ID: <20191112080401.GA2763@dhcp22.suse.cz> References: <1573510165-113395-1-git-send-email-yang.shi@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1573510165-113395-1-git-send-email-yang.shi@linux.alibaba.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 12-11-19 06:09:25, Yang Shi wrote: > When doing migration if the freed page is met, we just return without > migrating it since it is pointless to migrate a freed page. But, the > current code did two things before handling freed page: > > 1. Return -ENOMEM if the page is THP and THP migration is not supported. > 2. Allocate target page unconditionally. > > Both makes not too much sense. If we handle freed page at the first place > we don't have to worry about allocating/freeing target page and split > THP at all. > > For example (worst case) if we are trying to migrate a freed THP without > THP migration supported, the migrate_pages() would just split the THP then > retry to migrate base pages one by one by pointless allocating and freeing > pages, this is just waste of time. > > I didn't run into any actual problem with the current code (or I may > just not notice it yet), it was found by visual inspection. It would be preferable to accompany a change like this with some actual numbers. A race with page freeing should be a very rare situation. Maybe it is not under some workloads but that would better be checked and documented. I also do not like to do page state changes for THP migration without a support. I cannot really say this is 100% correct from top of my head and I do not see a sufficient justification to go and chase all those tiny details because that is time consuming. > Cc: Michal Hocko > Cc: Mel Gorman > Cc: Vlastimil Babka > Signed-off-by: Yang Shi > --- > mm/migrate.c | 18 +++++++----------- > 1 file changed, 7 insertions(+), 11 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index 4fe45d1..ef96997 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -1170,13 +1170,6 @@ static ICE_noinline int unmap_and_move(new_page_t get_new_page, > int rc = MIGRATEPAGE_SUCCESS; > struct page *newpage; > > - if (!thp_migration_supported() && PageTransHuge(page)) > - return -ENOMEM; > - > - newpage = get_new_page(page, private); > - if (!newpage) > - return -ENOMEM; > - > if (page_count(page) == 1) { > /* page was freed from under us. So we are done. */ > ClearPageActive(page); > @@ -1187,13 +1180,16 @@ static ICE_noinline int unmap_and_move(new_page_t get_new_page, > __ClearPageIsolated(page); > unlock_page(page); > } > - if (put_new_page) > - put_new_page(newpage, private); > - else > - put_page(newpage); > goto out; > } > > + if (!thp_migration_supported() && PageTransHuge(page)) > + return -ENOMEM; > + > + newpage = get_new_page(page, private); > + if (!newpage) > + return -ENOMEM; > + > rc = __unmap_and_move(page, newpage, force, mode); > if (rc == MIGRATEPAGE_SUCCESS) > set_page_owner_migrate_reason(newpage, reason); > -- > 1.8.3.1 > -- Michal Hocko SUSE Labs