Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp1853655rwo; Thu, 3 Aug 2023 00:14:04 -0700 (PDT) X-Google-Smtp-Source: APBJJlEM0RmHLKZOviRGRNn3n08txsIGrfBNwoCJ5ZULsa8kxXzGvL/c0QbjLEtNKrc7b6QKFM2C X-Received: by 2002:a05:6512:3e2a:b0:4fb:89f2:594d with SMTP id i42-20020a0565123e2a00b004fb89f2594dmr8120731lfv.63.1691046844262; Thu, 03 Aug 2023 00:14:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691046844; cv=none; d=google.com; s=arc-20160816; b=zuZPphv6deisAzzLbeq1C178rMf9wAuc5pp56P6m8jGquwiQbWAvocsZNiwuKMlolm sJ3+EoAK0r2glERTfKQVYZU/utIMiIShahFDVGlSVn4os7WJ9wnTTCCj8bGLdbVRB9U1 6F2sAUVA1rjQp5MLtwxVUhGcYhYswZvUxS1Rex6C//fB0wb3S4T5+/dQOjhR0z88vWko U1jZXtnBVJfNbx76pQm7Phk3FxIrtNqCIW10NjTMBgKhPre3HH6lMDiBbwUs5BlFZoag y67Ptar7o06S3w8294ivt9UAT5NQvkRbgOR3qfneaK2qVtvz4iHO8Ovid24wAnkS1g5t dNDw== 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:content-language:subject:user-agent:mime-version :date:message-id; bh=rZJJA08Ipam4moJbbO/nX+KRz/wWHgh4VmQE0V7cc+8=; fh=DMMbM3NPX8zgcuLrfKNs+qDrYrRtwgrt83aQtKmUGxI=; b=uZvwa0+2YTHxzkhNbA+ZqQJoBaEons/mgn6O61IhbMZRJU59+biobIqzyJ2xjHTEOE /OA6tP+hqzf/JIusXgecMf6Isfjh8sSbYa+v43PPO4in+dISBAkcy6LE8pfY2WocCJoS GCNT6F41qdE396D9MzGCZGJJ+Zw4h+JLHxbYrdhzwfFnSt0+Bq+U6HK8QhJldV5RryWg /4+sPjMQ0uyNma+AcwqLTiYx2FqIx4zIX5vMwW4qq8KVXds1pv1RXjhFAJqoj6W62eRR bXicO7qbKp4CcMXYoVU2gZHC02aBvBbm+nMpy76KTh7zXa90KScpX+bqZI5Uz7r1TEvz eIYA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m19-20020aa7c493000000b00523073530e8si1429448edq.25.2023.08.03.00.13.40; Thu, 03 Aug 2023 00:14:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233250AbjHCHIW (ORCPT + 99 others); Thu, 3 Aug 2023 03:08:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233046AbjHCHIQ (ORCPT ); Thu, 3 Aug 2023 03:08:16 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A52421BF1 for ; Thu, 3 Aug 2023 00:08:14 -0700 (PDT) Received: from dggpemm100001.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4RGfyp6XGKzVjr7; Thu, 3 Aug 2023 15:06:26 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Thu, 3 Aug 2023 15:08:10 +0800 Message-ID: <2f6c2ddb-b1a7-7152-bb7c-a5dcaf61ce36@huawei.com> Date: Thu, 3 Aug 2023 15:08:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: [PATCH 2/4] mm: migrate: convert numamigrate_isolate_page() to numamigrate_isolate_folio() Content-Language: en-US To: Matthew Wilcox , Hugh Dickins , Mel Gorman CC: Andrew Morton , , , Huang Ying , David Hildenbrand References: <20230802095346.87449-1-wangkefeng.wang@huawei.com> <20230802095346.87449-3-wangkefeng.wang@huawei.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm100001.china.huawei.com (7.185.36.93) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/8/2 20:30, Matthew Wilcox wrote: > On Wed, Aug 02, 2023 at 05:53:44PM +0800, Kefeng Wang wrote: >> -static int numamigrate_isolate_page(pg_data_t *pgdat, struct page *page) >> +static int numamigrate_isolate_folio(pg_data_t *pgdat, struct folio *folio) >> { >> - int nr_pages = thp_nr_pages(page); >> - int order = compound_order(page); >> + int nr_pages = folio_nr_pages(folio); >> + int order = folio_order(folio); >> >> - VM_BUG_ON_PAGE(order && !PageTransHuge(page), page); >> + VM_BUG_ON_FOLIO(order && !folio_test_pmd_mappable(folio), folio); > > I don't know why we have this assertion. I would be inclined to delete > it as part of generalising the migration code to handle arbitrary sizes > of folio, rather than assert that we only support PMD size folios. Ok, will drop it. > >> /* Do not migrate THP mapped by multiple processes */ >> - if (PageTransHuge(page) && total_mapcount(page) > 1) >> + if (folio_test_pmd_mappable(folio) && folio_estimated_sharers(folio) > 1) >> return 0; > > I don't know if this is the right logic. We've willing to move folios > mapped by multiple processes, as long as they're smaller than PMD size, > but once they get to PMD size they're magical and can't be moved? It seems that the logical is introduced by commit 04fa5d6a6547 ("mm: migrate: check page_count of THP before migrating") and refactor by 340ef3902cf2 ("mm: numa: cleanup flow of transhuge page migration"), "Hugh Dickins pointed out that migrate_misplaced_transhuge_page() does not check page_count before migrating like base page migration and khugepage. He could not see why this was safe and he is right." For now, there is no migrate_misplaced_transhuge_page() and base/thp page migrate's path is unified, there is a check(for old/new kernel) in migrate_misplaced_page(), "Don't migrate file pages that are mapped in multiple processes with execute permissions as they are probably shared libraries." We could drop the above check in numamigrate_isolate_page(), but according to 04fa5d6a6547, maybe disable migrate page shared by multi-process during numa balance for both base/thp page. > >