Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp1169719rdb; Wed, 20 Sep 2023 01:19:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH1Grr3RJ2Owyo2DnHBdKaoslM2AmNqcKeQcKZARLwIKXzmJ4qifhWzuUn1/f1nh3gFx/Yg X-Received: by 2002:a05:6a00:1995:b0:690:d718:8c6d with SMTP id d21-20020a056a00199500b00690d7188c6dmr1963081pfl.15.1695197973979; Wed, 20 Sep 2023 01:19:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695197973; cv=none; d=google.com; s=arc-20160816; b=Pqio/KOyg36Ok3c4wW+AMN7vZnt5QXyO6/QdrefgVQaTPXTWmN65m80a4Ofq01i18o q7VvhAukdtN6/KfithAv4r/wQtveeycRZRZc7diZ+Vx4qKHBnjV5obO5yQMVQ7lY1YDP zVWnP48M0R5nQZJM9A0olxH0wfbBfgSpoZz86NUNiAa/uzvYjzpPQtSK7EiHBsYmmsJb MBz0Hq6rUrXYqFIljpyGkvcIudSRAkuC+wOvOiqGvI7sK8kUqQ0qhfDoACZHkdYcd3eT xKea7O5pHhN8zcDF5w6VvEcCDPRVTTGmrNDvIA16lcJGp+jmMuQEsBExx4HgrQ8v+nI+ DPSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=+JWfPGsHasV9GbbuUYVNrmjTDYjemVcCfYxiLGmmdFA=; fh=OnMgtKqBwKMIBxrVr7LnadPyynuGI128irDDTys3U34=; b=menqxXCTpu0sVzzr4wopMSjxe/JGZ2Sq8awCWlWamg3APreb6gIcDk/+as6vLdBUui dtjAXdRnscTSSfEKfYecDEbRBPvDijTpguiHXu5pb6to1EA9CgUd+zBayIEhXLAyeux/ bThlF4zx0ULHwbCs/7UDZh53Zm/NT26q/6iwzlWdBOy8fAJaGAYMB1wV8UW6CC9tVrMV QMZUfvelcBH0uyufA26k/vAU0yrYNCejVyW5udacAFWv6nWa9DfICgIMmUdUvwRTJQDf 7R6P5UpB89jM15OKhNa6tD/k7J5h5KE03mfyI6sCp85ZOn/OpyrlkLClC3CBDEG0bIK9 VkiQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id x7-20020a654147000000b00573fa4cfe4asi11172227pgp.39.2023.09.20.01.19.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 01:19:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id E0F028256231; Wed, 20 Sep 2023 01:15:11 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232338AbjITIPJ (ORCPT + 99 others); Wed, 20 Sep 2023 04:15:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231347AbjITIPI (ORCPT ); Wed, 20 Sep 2023 04:15:08 -0400 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D79E9E for ; Wed, 20 Sep 2023 01:15:02 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R331e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046051;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0VsUU2iq_1695197698; Received: from 30.97.48.72(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0VsUU2iq_1695197698) by smtp.aliyun-inc.com; Wed, 20 Sep 2023 16:14:59 +0800 Message-ID: <0d92b375-c583-a21e-4e5b-355932a8b30e@linux.alibaba.com> Date: Wed, 20 Sep 2023 16:15:03 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [RFC PATCH 2/4] mm/compaction: optimize >0 order folio compaction with free page split. To: Zi Yan Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ryan Roberts , Andrew Morton , "Matthew Wilcox (Oracle)" , David Hildenbrand , "Yin, Fengwei" , Yu Zhao , Vlastimil Babka , Johannes Weiner , Kemeng Shi , Mel Gorman , Rohan Puri , Mcgrof Chamberlain , Adam Manzanares , John Hubbard References: <20230912162815.440749-1-zi.yan@sent.com> <20230912162815.440749-3-zi.yan@sent.com> <28f76c7c-4b84-5e08-2f27-07592d8078a2@linux.alibaba.com> <40CD5F50-FC29-46FB-A3E2-76C6D14D390E@nvidia.com> From: Baolin Wang In-Reply-To: <40CD5F50-FC29-46FB-A3E2-76C6D14D390E@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Wed, 20 Sep 2023 01:15:14 -0700 (PDT) On 9/19/2023 1:20 AM, Zi Yan wrote: > On 18 Sep 2023, at 3:34, Baolin Wang wrote: > >> On 9/13/2023 12:28 AM, Zi Yan wrote: >>> From: Zi Yan >>> >>> During migration in a memory compaction, free pages are placed in an array >>> of page lists based on their order. But the desired free page order (i.e., >>> the order of a source page) might not be always present, thus leading to >>> migration failures. Split a high order free pages when source migration >>> page has a lower order to increase migration successful rate. >>> >>> Note: merging free pages when a migration fails and a lower order free >>> page is returned via compaction_free() is possible, but there is too much >>> work. Since the free pages are not buddy pages, it is hard to identify >>> these free pages using existing PFN-based page merging algorithm. >>> >>> Signed-off-by: Zi Yan >>> --- >>> mm/compaction.c | 40 +++++++++++++++++++++++++++++++++++++++- >>> 1 file changed, 39 insertions(+), 1 deletion(-) >>> >>> diff --git a/mm/compaction.c b/mm/compaction.c >>> index 868e92e55d27..45747ab5f380 100644 >>> --- a/mm/compaction.c >>> +++ b/mm/compaction.c >>> @@ -1801,9 +1801,46 @@ static struct folio *compaction_alloc(struct folio *src, unsigned long data) >>> struct compact_control *cc = (struct compact_control *)data; >>> struct folio *dst; >>> int order = folio_order(src); >>> + bool has_isolated_pages = false; >>> +again: >>> if (!cc->freepages[order].nr_free) { >>> - isolate_freepages(cc); >>> + int i; >>> + >>> + for (i = order + 1; i <= MAX_ORDER; i++) { >>> + if (cc->freepages[i].nr_free) { >>> + struct page *freepage = >>> + list_first_entry(&cc->freepages[i].pages, >>> + struct page, lru); >>> + >>> + int start_order = i; >>> + unsigned long size = 1 << start_order; >>> + >>> + list_del(&freepage->lru); >>> + cc->freepages[i].nr_free--; >>> + >>> + while (start_order > order) { >>> + start_order--; >>> + size >>= 1; >>> + >>> + list_add(&freepage[size].lru, >>> + &cc->freepages[start_order].pages); >>> + cc->freepages[start_order].nr_free++; >>> + set_page_private(&freepage[size], start_order); >> >> IIUC, these split pages should also call functions to initialize? e.g. prep_compound_page()? > > Not at this place. It is done right below and above "done" label. When free pages > are on cc->freepages, we want to keep them without being post_alloc_hook() or > prep_compound_page() processed for a possible future split. A free page is > only initialized when it is returned by compaction_alloc(). Ah, I see. Thanks for explanation.