Message ID | cover.1692665449.git.baolin.wang@linux.alibaba.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b82d:0:b0:3f2:4152:657d with SMTP id z13csp3386488vqi; Mon, 21 Aug 2023 20:33:42 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEKbtaPqOHXHkM50+ixi4NFbjZ2bO1nFyLpprZtaA8oI2VnHCBEGVTLVKc8n/Gca8SYYKa/ X-Received: by 2002:aa7:dd14:0:b0:523:4bfa:b450 with SMTP id i20-20020aa7dd14000000b005234bfab450mr5176068edv.27.1692675222567; Mon, 21 Aug 2023 20:33:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1692675222; cv=none; d=google.com; s=arc-20160816; b=q7d2VsgAXzs65Z8mXvGGM0RvpwUzTYDxfqlhSFRjFG0qYfMLSnDp7g+u0HRc2CoCNK vfJmKl1EIIYv2LyqbMRHTHxGZ9qsqO+UDog7UYC1vgLatViELMRFcXH1IHnlAqJxBbo3 O2iRl7Qif4UXtx+AffNT00TujvswcPjSe176K8dHUgkvyxOVu2K6aa3ZZx5yGABoiRnR p1QxugUcRjOZkXR6ictODCY5mzcCFE/Ax+TCYNiEwDAVGU6TuYRdkRbputR7FrnBBHGL dncT6K4G1fcbKWGMilSVf2Py/KZ4NZvSivdroh1tSX7kj/Mkz4ZWEc7Cv23oAPy0IAlp CM+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=/aBVbB+Tu74xJDFWbv8zg3BiNT7LOcAazqgrJqmYe3Q=; fh=9/y/4i4wURkq6VSoO06mJGKzAg0FgvlCtHCXS3nYPok=; b=BuGd2NE+qPV89OMFEVlt30m5OOkz7vFf1BDlevb5R2mz7uFVFGPNE4EvDOcNKuOpVy JUk3ICWuVO1nVS/ZRU6T8hZw2O17YcVAoxzYmc5QbzvyzWDwhNI6y36IYdAVkdyQ93pV QatfPwuJt8050BLOSEoQpicnCANBL5eXVv2EPD1IWkDUymr41akbHin29NF9mpjRbYRV Tz+z2KevDqiz+JXpiANj7CciJFKnRjsbSZoS1m1z2IRUg/SJICFqsXMV3lXD791T/xn4 8yx8EG17LOPDvd8rAQyrPrYE4Rp2bpb/NRHM2E49OEpfjGOeAc5yeJXoHCAl9idfbGBx aQeA== 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=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b23-20020aa7df97000000b0052594fef88asi6827923edy.619.2023.08.21.20.33.15; Mon, 21 Aug 2023 20:33:42 -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=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231955AbjHVAyP (ORCPT <rfc822;telecom888@gmail.com> + 99 others); Mon, 21 Aug 2023 20:54:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58944 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231949AbjHVAyN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 21 Aug 2023 20:54:13 -0400 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3691183 for <linux-kernel@vger.kernel.org>; Mon, 21 Aug 2023 17:54:10 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R401e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0VqK0DOL_1692665646; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0VqK0DOL_1692665646) by smtp.aliyun-inc.com; Tue, 22 Aug 2023 08:54:07 +0800 From: Baolin Wang <baolin.wang@linux.alibaba.com> To: akpm@linux-foundation.org Cc: mgorman@techsingularity.net, shy828301@gmail.com, david@redhat.com, ying.huang@intel.com, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/4] Extend migrate_misplaced_page() to support batch migration Date: Tue, 22 Aug 2023 08:53:48 +0800 Message-Id: <cover.1692665449.git.baolin.wang@linux.alibaba.com> X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1774898614409865284 X-GMAIL-MSGID: 1774898614409865284 |
Series |
Extend migrate_misplaced_page() to support batch migration
|
|
Message
Baolin Wang
Aug. 22, 2023, 12:53 a.m. UTC
Hi, Currently, on our ARM servers with NUMA enabled, we found the cross-die latency is a little larger that will significantly impact the workload's performance. So on ARM servers we will rely on the NUMA balancing to avoid the cross-die accessing. And I posted a patchset[1] to support speculative numa fault to improve the NUMA balancing's performance according to the principle of data locality. Moreover, thanks to Huang Ying's patchset[2], which introduced batch migration as a way to reduce the cost of TLB flush, and it will also benefit the migration of multiple pages all at once during NUMA balancing. So we plan to continue to support batch migration in do_numa_page() to improve the NUMA balancing's performance, but before adding complicated batch migration algorithm for NUMA balancing, some cleanup and preparation work need to do firstly, which are done in this patch set. In short, this patchset extends the migrate_misplaced_page() interface to support batch migration, and no functional changes intended. In addition, these cleanup can also benefit the compound page's NUMA balancing, which was discussed in previous thread[3]. IIUC, for the compound page's NUMA balancing, it is possible that partial pages were successfully migrated, so it is necessary to return the number of pages that were successfully migrated from migrate_misplaced_page(). This series is based on the latest mm-unstable(d226b59b30cc). [1] https://lore.kernel.org/lkml/cover.1639306956.git.baolin.wang@linux.alibaba.com/t/#mc45929849b5d0e29b5fdd9d50425f8e95b8f2563 [2] https://lore.kernel.org/all/20230213123444.155149-1-ying.huang@intel.com/T/#u [3] https://lore.kernel.org/all/f8d47176-03a8-99bf-a813-b5942830fd73@arm.com/ Changes from v1: - Move page validation into a new function suggested by Huang Ying. - Change numamigrate_isolate_page() to boolean type. - Update some commit message. Baolin Wang (4): mm: migrate: factor out migration validation into numa_page_can_migrate() mm: migrate: move the numamigrate_isolate_page() into do_numa_page() mm: migrate: change migrate_misplaced_page() to support multiple pages migration mm: migrate: change to return the number of pages migrated successfully include/linux/migrate.h | 15 +++++++--- mm/huge_memory.c | 23 +++++++++++++-- mm/internal.h | 1 + mm/memory.c | 43 ++++++++++++++++++++++++++- mm/migrate.c | 64 +++++++++-------------------------------- 5 files changed, 88 insertions(+), 58 deletions(-)
Comments
On 8/24/2023 12:51 PM, Huang, Ying wrote: > Baolin Wang <baolin.wang@linux.alibaba.com> writes: > >> On 8/22/2023 10:47 AM, Huang, Ying wrote: >>> Baolin Wang <baolin.wang@linux.alibaba.com> writes: >>> >>>> Hi, >>>> >>>> Currently, on our ARM servers with NUMA enabled, we found the cross-die latency >>>> is a little larger that will significantly impact the workload's performance. >>>> So on ARM servers we will rely on the NUMA balancing to avoid the cross-die >>>> accessing. And I posted a patchset[1] to support speculative numa fault to >>>> improve the NUMA balancing's performance according to the principle of data >>>> locality. Moreover, thanks to Huang Ying's patchset[2], which introduced batch >>>> migration as a way to reduce the cost of TLB flush, and it will also benefit >>>> the migration of multiple pages all at once during NUMA balancing. >>>> >>>> So we plan to continue to support batch migration in do_numa_page() to improve >>>> the NUMA balancing's performance, but before adding complicated batch migration >>>> algorithm for NUMA balancing, some cleanup and preparation work need to do firstly, >>>> which are done in this patch set. In short, this patchset extends the >>>> migrate_misplaced_page() interface to support batch migration, and no functional >>>> changes intended. >>>> >>>> In addition, these cleanup can also benefit the compound page's NUMA balancing, >>>> which was discussed in previous thread[3]. IIUC, for the compound page's NUMA >>>> balancing, it is possible that partial pages were successfully migrated, so it is >>>> necessary to return the number of pages that were successfully migrated from >>>> migrate_misplaced_page(). >>> But I don't find the return number is used except as bool now. >> >> As I said above, this is a preparation for batch migration and >> compound page NUMA balancing in future. >> >> In addition, after looking into the THP' NUMA migration, I found this >> change is necessary for THP migration. Since it is possible that >> partial subpages were successfully migrated if the THP is split, so >> below THP numa fault statistics is not always correct: >> >> if (page_nid != NUMA_NO_NODE) >> task_numa_fault(last_cpupid, page_nid, HPAGE_PMD_NR, >> flags); >> >> I will try to fix this in next version. > > IIUC, THP will not be split for NUMA balancing. Please check the > nosplit logic in migrate_pages_batch(). > > bool nosplit = (reason == MR_NUMA_MISPLACED); Yes, I overlooked this. Thanks for reminding. > >>> Per my understanding, I still don't find much value of the changes >>> except as preparation for batch migration in NUMA balancing. So I still >> >> IMO, only patch 3 is just a preparation for batch migration, but other >> patches are some cleanups for migrate_misplaced_page(). I can drop the >> preparation patches in this series and revise the commit message. >> >>> think it's better to wait for the whole series. Where we can check why >>> these changes are necessary for batch migration. And I think that you >>> will provide some number to justify the batch migration, including pros >>> and cons. >>> -- >>> Best Regards, >>> Huang, Ying >>> >>>> This series is based on the latest mm-unstable(d226b59b30cc). >>>> >>>> [1] https://lore.kernel.org/lkml/cover.1639306956.git.baolin.wang@linux.alibaba.com/t/#mc45929849b5d0e29b5fdd9d50425f8e95b8f2563 >>>> [2] https://lore.kernel.org/all/20230213123444.155149-1-ying.huang@intel.com/T/#u >>>> [3] https://lore.kernel.org/all/f8d47176-03a8-99bf-a813-b5942830fd73@arm.com/ >>>> >>>> Changes from v1: >>>> - Move page validation into a new function suggested by Huang Ying. >>>> - Change numamigrate_isolate_page() to boolean type. >>>> - Update some commit message. >>>> >>>> Baolin Wang (4): >>>> mm: migrate: factor out migration validation into >>>> numa_page_can_migrate() >>>> mm: migrate: move the numamigrate_isolate_page() into do_numa_page() >>>> mm: migrate: change migrate_misplaced_page() to support multiple pages >>>> migration >>>> mm: migrate: change to return the number of pages migrated >>>> successfully >>>> >>>> include/linux/migrate.h | 15 +++++++--- >>>> mm/huge_memory.c | 23 +++++++++++++-- >>>> mm/internal.h | 1 + >>>> mm/memory.c | 43 ++++++++++++++++++++++++++- >>>> mm/migrate.c | 64 +++++++++-------------------------------- >>>> 5 files changed, 88 insertions(+), 58 deletions(-)