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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FE0EC4332F for ; Tue, 14 Nov 2023 11:11:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232764AbjKNLLw (ORCPT ); Tue, 14 Nov 2023 06:11:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbjKNLLv (ORCPT ); Tue, 14 Nov 2023 06:11:51 -0500 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35DE318C for ; Tue, 14 Nov 2023 03:11:47 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R871e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046050;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0VwPD2sM_1699960303; Received: from 30.97.48.66(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0VwPD2sM_1699960303) by smtp.aliyun-inc.com; Tue, 14 Nov 2023 19:11:44 +0800 Message-ID: Date: Tue, 14 Nov 2023 19:11:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm: support large folio numa balancing To: "Huang, Ying" , David Hildenbrand Cc: akpm@linux-foundation.org, wangkefeng.wang@huawei.com, willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, John Hubbard , Mel Gorman , Peter Zijlstra References: <606d2d7a-d937-4ffe-a6f2-dfe3ae5a0c91@redhat.com> <871qctf89m.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Baolin Wang In-Reply-To: <871qctf89m.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/14/2023 9:12 AM, Huang, Ying wrote: > David Hildenbrand writes: > >> On 13.11.23 11:45, Baolin Wang wrote: >>> Currently, the file pages already support large folio, and supporting for >>> anonymous pages is also under discussion[1]. Moreover, the numa balancing >>> code are converted to use a folio by previous thread[2], and the migrate_pages >>> function also already supports the large folio migration. >>> So now I did not see any reason to continue restricting NUMA >>> balancing for >>> large folio. >> >> I recall John wanted to look into that. CCing him. >> >> I'll note that the "head page mapcount" heuristic to detect sharers will >> now strike on the PTE path and make us believe that a large folios is >> exclusive, although it isn't. > > Even 4k folio may be shared by multiple processes/threads. So, numa > balancing uses a multi-stage node selection algorithm (mostly > implemented in should_numa_migrate_memory()) to identify shared folios. > I think that the algorithm needs to be adjusted for PTE mapped large > folio for shared folios. Not sure I get you here. In should_numa_migrate_memory(), it will use last CPU id, last PID and group numa faults to determine if this page can be migrated to the target node. So for large folio, a precise folio sharers check can make the numa faults of a group more accurate, which is enough for should_numa_migrate_memory() to make a decision? Could you provide a more detailed description of the algorithm you would like to change for large folio? Thanks. > And, as a performance improvement patch, some performance data needs to Do you have some benchmark recommendation? I know the the autonuma can not support large folio now. > be provided. And, the effect of shared folio detection needs to be > tested too