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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AF3DC433F5 for ; Sun, 7 Nov 2021 09:33:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F377361058 for ; Sun, 7 Nov 2021 09:33:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F377361058 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 72C5C6B00DF; Sun, 7 Nov 2021 04:33:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DD576B00E1; Sun, 7 Nov 2021 04:33:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D43D6B00DF; Sun, 7 Nov 2021 04:33:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id 490836B00DF for ; Sun, 7 Nov 2021 04:33:01 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 05D6D6E6BF for ; Sun, 7 Nov 2021 09:33:01 +0000 (UTC) X-FDA: 78781620162.04.A0B5B26 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) by imf18.hostedemail.com (Postfix) with ESMTP id 214F440020B7 for ; Sun, 7 Nov 2021 09:32:58 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0UvOEnjO_1636277573; Received: from 30.30.76.41(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0UvOEnjO_1636277573) by smtp.aliyun-inc.com(127.0.0.1); Sun, 07 Nov 2021 17:32:56 +0800 Subject: Re: [RFC PATCH] mm: migrate: Add new node demotion strategy To: Dave Hansen , "Huang, Ying" Cc: akpm@linux-foundation.org, dave.hansen@linux.intel.com, ziy@nvidia.com, osalvador@suse.de, shy828301@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <665cb882-6dbc-335f-1435-e52659d7ee58@intel.com> <87tugrxqks.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Baolin Wang Message-ID: <240c5997-ab7e-8045-dacc-1afdb7c49a0d@linux.alibaba.com> Date: Sun, 7 Nov 2021 17:33:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 214F440020B7 X-Stat-Signature: yc7j6y7ren8y58xmcb7p3b6ngu1zqbbt Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.133 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com X-HE-Tag: 1636277578-55985 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 2021/11/5 23:47, Dave Hansen wrote: > On 11/4/21 7:51 PM, Huang, Ying wrote: >>> Let's also try to do it with the existing node_demotion[] data >>> structure before we go adding more. >> To avoid cache ping-pong, I guess some kind of per-CPU data structure >> may be more suitable for interleaving among multiple nodes. > > It would probably be better to just find something that's more > read-heavy. Like, instead of keeping a strict round-robin, just > randomly select one of the notes to which you can round-robin. > > That will scale naturally without having to worry about caching or fancy > per-cpu data structures. > Thanks for your suggestion. After some thinking, can we change the node_demotion[] structure like below? Which means one source node can be demoted to mutiple target node, and we can set up the target node mask according to the node distance. How do you think? Thanks. static nodemask_t node_demotion[MAX_NUMNODES] __read_mostly = {[0 ... MAX_NUMNODES - 1] = NODE_MASK_NONE};