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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D37DC7115C for ; Wed, 25 Jun 2025 06:11:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F6506B00B6; Wed, 25 Jun 2025 02:11:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A6B16B00B7; Wed, 25 Jun 2025 02:11:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFF616B00B8; Wed, 25 Jun 2025 02:11:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DD7A86B00B6 for ; Wed, 25 Jun 2025 02:11:41 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 911FD105EA9 for ; Wed, 25 Jun 2025 06:11:41 +0000 (UTC) X-FDA: 83592901602.26.7C83318 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) by imf10.hostedemail.com (Postfix) with ESMTP id E7622C0005 for ; Wed, 25 Jun 2025 06:11:38 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=V0NAbayk; spf=pass (imf10.hostedemail.com: domain of ying.huang@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=ying.huang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750831900; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=76DnGSmj2vkYfuP0EwAnTPcRa1vP+wuz/cSNTM/iBy8=; b=VECuN0WgrZx0SiZ87fPq57qET2wJ3HNccVhQsPz09sK0Oi/Pfcj87SWG0LGng3jdjXefJ/ lvJLP52qpYOAIMsDnzzWRhDm5x5IImjMiNPTfyNIWTPg7CY/SAXY0QCnPmgm+KXkWkE+6q ngOO4EUrinD53NIG2ewQGo4FtSDhlFw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750831900; a=rsa-sha256; cv=none; b=rnbsysetpsqoqr2ZQz3RbrB6VpEobQXO6FzhrwWZ32KFtJU3e75VwT4V90LVD3SEKiDmNC 7pI2UwDnd1k5ZZNfJvIDtwZwA9BKzmyNxHv0RywAP5qxlfAotmX9rh1oX2HP/S19H+Z4qX S2m8DHjH0Ejjf4JsHXBEBfo+qCMiUt0= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=V0NAbayk; spf=pass (imf10.hostedemail.com: domain of ying.huang@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=ying.huang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1750831895; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=76DnGSmj2vkYfuP0EwAnTPcRa1vP+wuz/cSNTM/iBy8=; b=V0NAbayk2W5GH7/2EIFZf+Li+JrQnbDn2CqAiT4ymuQB6BL1dRngKWz00KgvEEsJ7/fgnYcBYqWtU2kr5Nihf5yUgufP56TD4hJdM8kKdzY5oNVVgM8zz8cvdv4RIrEyIx7M9k1IfdGJ2bu2pIob6McbdoY3C3nYM8x7QE4bJ6A= Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0WetkeAe_1750831892 cluster:ay36) by smtp.aliyun-inc.com; Wed, 25 Jun 2025 14:11:33 +0800 From: "Huang, Ying" To: Li Zhijian Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, y-goto@fujitsu.com, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , lkp@intel.com Subject: Re: [PATCH RFC v2] mm: memory-tiering: Fix PGPROMOTE_CANDIDATE accounting In-Reply-To: <20250625021352.2291544-1-lizhijian@fujitsu.com> (Li Zhijian's message of "Wed, 25 Jun 2025 10:13:52 +0800") References: <20250625021352.2291544-1-lizhijian@fujitsu.com> Date: Wed, 25 Jun 2025 14:11:32 +0800 Message-ID: <877c10mju3.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E7622C0005 X-Stat-Signature: 5u8i46mejy8wsk1nog4fnqufraczy98e X-Rspam-User: X-HE-Tag: 1750831898-880605 X-HE-Meta: U2FsdGVkX19QzcIxmPWCDaOAcEgp4rdjTj/y4gpAZczKNSJIH2GgpMpBL270f0ChIDEpfCwjkhWVLHXYC7bH8qnRrdtyvBQglmyynCBSEJn9xfDDMpjzInvYZ9mexD6oGbsqVabprr36LzRqO6bMI1ZIBDc7Mw27Fo2/XZLDHKHHUxH7cVDV3kpPJCHAdrZUAHMv+0SYOM7Urp1j4Dl1RE8Y0erIi37cAZqWWNWsyUXKJUsPVBKKwBQbMDV3mssFZLRnMfpjBVt8SZaR/LQvUV1l9j97XBj+u9IjZOt83JX+TO+Umw5jG/lOyGhiD7Q6/qzIQpvbLTIDtYa5wmjqxIsJ9dKZVMh05mniHToMiV+SHvQQ8N5sfD29dvaiCD+LPjeFn+BFUVV9YR2A3Rh5usNRqXQ7EkV8Al8gv5vgxnhVPFxRltkGyil8UQpaMyEJ/+MITZC9nZ4Yc9dMGoP8MXDyDjzkzQIrIj/hZi5fRMB52XOeioXUCDHm1sQDMl/y26cErn6G+tXXbNYBQNhR+3lm5bwtJ5wZ3YCbD4bacIrk63Xsi2h92DDPfEVjT8ClgW+AnO6YEOwgHMIg+C//toCpF4rkoJCWO4pKdFIJR0KdrEu9u3u9BNUvFSRpDia3jXbEMi/L7up2bFAb9jUKdqFq+3r8vKGrLdcCcM+IIFmlxlUNL4QWHF9964F8lX74hZ6fuVNjc6Js/kWyZ5WfYN0gc2GogzJFCCLbq2ujK0m7yZmm6Q0KDXzJ6RYVXNldErOYKzu1dVPPy0TeMeztjLOxdvl4lOQVmaiXTpnzmh5zshWmPan75NpLhg8XtgVuyQtXW+16YDHXjQGtradE2G3HjJruNlsIhgh8CistKfsGnzRRDkZH6hWed9iejBs4WoariIak6IScR5wF4Z0LTbCi750fJ8Lle22UMGcSc2Wx2m2zk8UtYmqn1GSqNU2jpxaqBb/mu35uOMXArUc qBFh+xVP APoPufNUcXnfMM3q1zaRm0XR0t6T56XOttes+Jkyi7kVPhsCnRSfeLZpsH9i7gCh3LXEfZCUWCy86qm53eTn8T1sjaBffSoBzSlvsDe+DQUQ9lNUBWqmyveMm3Txx0fHE3AUe1gxDRMnwQKK2mFuoQv3hAmkIAQQVvJLn+zQWDOM18WWMRrfmkLRLeKHZJIzKSZ++9b9UlXMvn8YnDZN9MfrJqmThBfslJls+gyR6r0wWrg6wOorH4exXCGDZLbj9xJCkbHfncmwORteA+s70KNYBoW2VVJCwBDSdcgqk/iSbys7IWulxH/DaIKCDkszDPDnI2ILu3aXhz6H6Q7WYl8rJGgL2t8h8jhlScyPW9AB/lIw+JaivYAO4ZPqN1wdHcCFEUn5amclBojn7uPm9Kd56G025mwH8UMnruSUEbk+6trL9XZtHx5yiitW8slMkhzLoAq4gNFx2HA6ZXdpZS1Cf0lmHUS5lwNKOrrEH9flCTiVGxN4JzxUqQEVdxeuCMGtDEq+CpG4COFw3VXV8Jb0HfKyUMrPb8RoWBI4MMPwtxhRvKPj53TfXxb3CXO3hPRcVj3+T8npHAiO2RJIXL5Vf2V9k+bjZ5J1vBwpCTWlOM7XRxEWa8DwV4beAUGCtpCggbtNND479I9c= 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: List-Subscribe: List-Unsubscribe: Li Zhijian writes: > Goto-san reported confusing pgpromote statistics where > the pgpromote_success count significantly exceeded pgpromote_candidate. > > On a system with three nodes (nodes 0-1: DRAM 4GB, node 2: NVDIMM 4GB): > # Enable demotion only > echo 1 > /sys/kernel/mm/numa/demotion_enabled > numactl -m 0-1 memhog -r200 3500M >/dev/null & > pid=$! > sleep 2 > numactl memhog -r100 2500M >/dev/null & > sleep 10 > kill -9 $pid # terminate the 1st memhog > # Enable promotion > echo 2 > /proc/sys/kernel/numa_balancing > > After a few seconds, we observeed `pgpromote_candidate < pgpromote_success` > $ grep -e pgpromote /proc/vmstat > pgpromote_success 2579 > pgpromote_candidate 0 > > In this scenario, after terminating the first memhog, the conditions for > pgdat_free_space_enough() are quickly met, triggering promotion. > However, these migrated pages are only accounted for in PGPROMOTE_SUCCESS, > not in PGPROMOTE_CANDIDATE. > > This update increments PGPROMOTE_CANDIDATE within the free space branch > when a promotion decision is made, which may alter the mechanism of the > rate limit. Consequently, it becomes easier to reach the rate limit than > it was previously. > > For example: > Rate Limit = 100 pages/sec > Scenario: > T0: 90 free-space migrations > T0+100ms: 20-page migration request > > Before: > Rate limit is *not* reached: 0 + 20 = 20 < 100 > PGPROMOTE_CANDIDATE: 20 > After: > Rate limit is reached: 90 + 20 = 110 > 100 > PGPROMOTE_CANDIDATE: 110 > > Due to the fact that the rate limit mechanism recalculates every second, > theoretically, only within that one second can the transition from > pgdat_free_space_enough() to !pgdat_free_space_enough() in top-tier > remaining memory be affected. > > Moreover, previously, within this one-second span, promotions caused by > pgdat_free_space_enough() are not restricted by rate limits. > This theoretically makes it easier to cause application latency. > > The current modification can better control the rate limit in cases of > transition from pgdat_free_space_enough() to !pgdat_free_space_enough() > within one second. > > Cc: Huang Ying > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Juri Lelli > Cc: Vincent Guittot > Cc: Dietmar Eggemann > Cc: Steven Rostedt > Cc: Ben Segall > Cc: Mel Gorman > Cc: Valentin Schneider > Reported-by: Yasunori Gotou (Fujitsu) > Signed-off-by: Li Zhijian > --- > V2: > Fix compiling error # Reported by LKP > > As Ying suggested, we need to assess whether this change causes regression. > However, considering the stringent conditions this patch involves, > properly evaluating it may be challenging, as the outcomes depend on your > perspective. Much like in a zero-sum game, if someone benefits, another > might lose. > > If there are subsequent results, I will update them here. I understand that it's hard to identify all possible regressions. However, at least done some test to check some common use cases? > Cc: lkp@intel.com > Here, I hope to leverage the existing LKP benchmark to evaluate the > potential impacts. The ideal evaluation conditions are: > 1. Installed with DRAM + NVDIMM (which can be simulated). > 2. NVDIMM is used as system RAM (configurable via daxctl). > 3. Promotion is enabled (`echo 2 > /proc/sys/kernel/numa_balancing`). > > Alternative: > We can indeed eliminate the potential impact within > pgdat_free_space_enough(), so that the rate limit behavior remains as > before. > > For instance, consider the following change: > if (pgdat_free_space_enough(pgdat)) { > /* workload changed, reset hot threshold */ > pgdat->nbp_threshold = 0; > + pgdat->nbp_rl_nr_cand += nr; > mod_node_page_state(pgdat, PGPROMOTE_CANDIDATE, nr); > return true; > } > > RFC: > I am uncertain whether we originally intended for this discrepancy or if > it was overlooked. > > However, the current situation where pgpromote_candidate < pgpromote_success > is indeed confusing when interpreted literally. > --- > kernel/sched/fair.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 7a14da5396fb..505b40f8897a 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -1940,11 +1940,13 @@ bool should_numa_migrate_memory(struct task_struct *p, struct folio *folio, > struct pglist_data *pgdat; > unsigned long rate_limit; > unsigned int latency, th, def_th; > + long nr = folio_nr_pages(folio); > > pgdat = NODE_DATA(dst_nid); > if (pgdat_free_space_enough(pgdat)) { > /* workload changed, reset hot threshold */ > pgdat->nbp_threshold = 0; > + mod_node_page_state(pgdat, PGPROMOTE_CANDIDATE, nr); > return true; > } > > @@ -1958,8 +1960,7 @@ bool should_numa_migrate_memory(struct task_struct *p, struct folio *folio, > if (latency >= th) > return false; > > - return !numa_promotion_rate_limit(pgdat, rate_limit, > - folio_nr_pages(folio)); > + return !numa_promotion_rate_limit(pgdat, rate_limit, nr); > } > > this_cpupid = cpu_pid_to_cpupid(dst_cpu, current->pid); --- Best Regards, Huang, Ying