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 1C377C54798 for ; Thu, 29 Feb 2024 08:50:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB78F6B006E; Thu, 29 Feb 2024 03:50:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A67B36B0092; Thu, 29 Feb 2024 03:50:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92FE36B0083; Thu, 29 Feb 2024 03:50:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7D5D26B00B9 for ; Thu, 29 Feb 2024 03:50:58 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3AA4D1C121A for ; Thu, 29 Feb 2024 08:50:58 +0000 (UTC) X-FDA: 81844221396.15.9254345 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf23.hostedemail.com (Postfix) with ESMTP id 030EB14000B for ; Thu, 29 Feb 2024 08:50:52 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709196656; 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; bh=epHOKHvlkrGsjbVpSo3P64X7ucEVY4PE2F/9liB6JyU=; b=EbJtVIjlgPfsM3rliPDV2bMgBO2Qu0nWvXgxV7h4WxIsAkJRi4lvg29XG69yRo1Gcq5NrX pYvb3w5zdSmN+nNgdImveuoo6QlC60LsEFqpPa81OphOk07oBD1a/+lBjCFiByuUDe4ANa fMVD8479UEIs/njsa6k5CIpGQenEpKA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709196656; a=rsa-sha256; cv=none; b=KMID99mX7ERO/OskCVrfxYfLvzycakN7+quatgkPIWVpXZltsntKs7WnZftTefFLgE0Z4T Nfn0RMFb0H+26FiSG5Y8cVStho+aX3J0CtW7zfDLTSxJxcyWKXh5HgIWG2bsodrBTLsZX5 t2tYPeFb23DdSgTqr0o75w64AJQxwNA= X-AuditID: a67dfc5b-d85ff70000001748-ed-65e045690d75 Date: Thu, 29 Feb 2024 17:50:44 +0900 From: Byungchul Park To: "Huang, Ying" Cc: Johannes Weiner , Michal Hocko , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, yuzhao@google.com, Mel Gorman , Vlastimil Babka Subject: Re: [PATCH v3] mm, vmscan: do not turn on cache_trim_mode if it doesn't work Message-ID: <20240229085044.GB64252@system.software.com> References: <20240223054407.14829-1-byungchul@sk.com> <20240228223601.GA53666@cmpxchg.org> <87jzmndc4k.fsf@yhuang6-desk2.ccr.corp.intel.com> <20240229083938.GA64252@system.software.com> <871q8vd5n5.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871q8vd5n5.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsXC9ZZnkW6m64NUgxmXNSzmrF/DZrF6k6/F 5V1z2CzurfnPajH53TNGi/t9DhazG/sYLU7Omsxi8W7CF1YHTo/Db94zeyzYVOqxeM9LJo9N nyaxe5yY8ZvFY/2WqyweZxYcYffYfLra4/MmuQDOKC6blNSczLLUIn27BK6MCweaWQt+R1dc PP6evYFxhUsXIyeHhICJxLT5h9hg7P/PfzGC2CwCqhL/v05iAbHZBNQlbtz4yQxiiwhoSHxa uJy9i5GLg1mgnUmi7fA0sCJhgXCJjrm7WUFsXgELiU87+thAioQEJjFJfH52hAkiIShxcuYT sAZmAS2JG/9eAsU5gGxpieX/OEDCnAJ2Evde7QI7SFRAWeLAtuNMIHMkBG6zSSy9foUZ4lJJ iYMrbrBMYBSYhWTsLCRjZyGMXcDIvIpRKDOvLDcxM8dEL6MyL7NCLzk/dxMjMCaW1f6J3sH4 6ULwIUYBDkYlHt4Em/upQqyJZcWVuYcYJTiYlUR4ZQTvpgrxpiRWVqUW5ccXleakFh9ilOZg URLnNfpWniIkkJ5YkpqdmlqQWgSTZeLglGpgZDSQVK+weHtRl9P7VtGrhkm3tdfIp65UfnSG zzzQ8OwXywUrTm4Wcl/l2+T55wbjMsn27X1XAyfaCDbeLOVrfhjOPdfunreLSfoKvi7ZxH+v 3Ep8py4u2fL92aTp2xd4KTdEPD9TzBOg1C72rupGMFNUT1vM8ogXG10nXpzhP32tzcW8HUKC SizFGYmGWsxFxYkAt6QMTYUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsXC5WfdrJvp+iDV4ON7GYs569ewWaze5Gtx eO5JVovLu+awWdxb85/VYvK7Z4wW9/scLGY39jFanJw1mcXi3YQvrA5cHoffvGf2WLCp1GPx npdMHps+TWL3ODHjN4vH4hcfmDzWb7nK4nFmwRF2j82nqz0+b5IL4IrisklJzcksSy3St0vg yrhwoJm14Hd0xcXj79kbGFe4dDFyckgImEj8f/6LEcRmEVCV+P91EguIzSagLnHjxk9mEFtE QEPi08Ll7F2MXBzMAu1MEm2Hp4EVCQuES3TM3c0KYvMKWEh82tHHBlIkJDCJSeLzsyNMEAlB iZMzn4A1MAtoSdz49xIozgFkS0ss/8cBEuYUsJO492oXG4gtKqAscWDbcaYJjLyzkHTPQtI9 C6F7ASPzKkaRzLyy3MTMHFO94uyMyrzMCr3k/NxNjMAAX1b7Z+IOxi+X3Q8xCnAwKvHwJtjc TxViTSwrrsw9xCjBwawkwisjeDdViDclsbIqtSg/vqg0J7X4EKM0B4uSOK9XeGqCkEB6Yklq dmpqQWoRTJaJg1OqgdHA5EnfzqPSs4IkZ/m5bN14dMbJ9T/FHPPnGYe9NlXjerDqYHzFRua9 z3/HX5Naq2+d/nEpy2f5l4v6/jn0ZV/cEOM/7yrXPcWZCheDs/oUGtYclqq6Gr2ulD3V9+j3 fYlVdXGi6fJxkhanE56GnenaqaDAfGALz57wNqsdn6JjJ1mWrn/9860SS3FGoqEWc1FxIgDh zAb+bAIAAA== X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 030EB14000B X-Rspam-User: X-Stat-Signature: khsbj1puahbcfwnzhuouneefzqqi5hmg X-Rspamd-Server: rspam01 X-HE-Tag: 1709196652-853338 X-HE-Meta: U2FsdGVkX18wastvg7M0JXIr5SSw9DMwds2BJXR0OJw72krXhCQjvlTX+TI7s/dlQGy0ZeQJFBVF/62LhcszsWvNFF0cGjbyEJYr90KGp7Ywmwhm5WlqZvutYXDEnTY1a6tfK8N6yuhUKx0K7j4FeXIgGq6JWO0ZkX9wODMkazpg384G70KYyIScN1IyXuAJOJVXlUWJCabM5uGKG7g0Yv8gw5SYzkUBoXFnkhYFXzpWOxS9dYguszFdVgLFntoqxhMSaDtb4/1EfbUZsxM4fvnkmfgKnwr8jrvkFt6PEMCR8blOK6E4wsFsC3OqHmIsRQJZeGcC1cGjR78/QEXfF0az2zD5EONrka1G2fFfI3bXKTnMp9PbQ3oq9dg3vkVIpSojebY0lJO3EyIu/DP5XFKP2hGmJvi3I28O93L0k87sp3a7GdNu70C9sRm9Xx8fGZOHmyocetTSRDwKK0PSWb+ZMnagJskFpD4GGcTBqPJ4bSxBlsoefVJ6JpzjkKFa/gtmD3lJkFqEFjyMCNsYHLWMHD1U+AOuEicoIsLBGvn4EnpJ3G4eUpsNgI8Vp0QhWcoLa/XvgqgnVrN8FnmjkotFib1K4uWH/iuMsrzTbhTCy31tIimZ+YVU6Z9Iq1TOW0CnRoDG24w+lFgMjEJPo1gZuHYxWDBdZVAkiNjQZEj3UPprf9bxGO2jvy58D9WoXaecsJRnpkyIGwlPFZJYNQ== 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: On Thu, Feb 29, 2024 at 04:41:18PM +0800, Huang, Ying wrote: > Byungchul Park writes: > > > On Thu, Feb 29, 2024 at 02:21:15PM +0800, Huang, Ying wrote: > >> Johannes Weiner writes: > >> > >> > On Mon, Feb 26, 2024 at 02:06:30PM +0100, Michal Hocko wrote: > >> >> [CC Mel, Vlastimil and Johannes for awareness] > >> >> > >> >> On Fri 23-02-24 14:44:07, Byungchul Park wrote: > >> >> > Changes from v2: > >> >> > 1. Change the condition to stop cache_trim_mode. > >> >> > > >> >> > From - Stop it if it's at high scan priorities, 0 or 1. > >> >> > To - Stop it if it's at high scan priorities, 0 or 1, and > >> >> > the mode didn't work in the previous turn. > >> >> > > >> >> > (feedbacked by Huang Ying) > >> >> > > >> >> > 2. Change the test result in the commit message after testing > >> >> > with the new logic. > >> >> > > >> >> > Changes from v1: > >> >> > 1. Add a comment describing why this change is necessary in code > >> >> > and rewrite the commit message with how to reproduce and what > >> >> > the result is using vmstat. (feedbacked by Andrew Morton and > >> >> > Yu Zhao) > >> >> > 2. Change the condition to avoid cache_trim_mode from > >> >> > 'sc->priority != 1' to 'sc->priority > 1' to reflect cases > >> >> > where the priority goes to zero all the way. (feedbacked by > >> >> > Yu Zhao) > >> >> > > >> >> > --->8--- > >> >> > >From 05846e34bf02ac9b3e254324dc2d7afd97a025d9 Mon Sep 17 00:00:00 2001 > >> >> > From: Byungchul Park > >> >> > Date: Fri, 23 Feb 2024 13:47:16 +0900 > >> >> > Subject: [PATCH v3] mm, vmscan: do not turn on cache_trim_mode if it doesn't work > >> >> > > >> >> > With cache_trim_mode on, reclaim logic doesn't bother reclaiming anon > >> >> > pages. However, it should be more careful to turn on the mode because > >> >> > it's going to prevent anon pages from being reclaimed even if there are > >> >> > a huge number of anon pages that are cold and should be reclaimed. Even > >> >> > worse, that leads kswapd_failures to reach MAX_RECLAIM_RETRIES and > >> >> > stopping kswapd from functioning until direct reclaim eventually works > >> >> > to resume kswapd. > >> >> > > >> >> > So do not turn on cache_trim_mode if the mode doesn't work, especially > >> >> > while the sytem is struggling against reclaim. > >> >> > > >> >> > The problematic behavior can be reproduced by: > >> >> > > >> >> > CONFIG_NUMA_BALANCING enabled > >> >> > sysctl_numa_balancing_mode set to NUMA_BALANCING_MEMORY_TIERING > >> >> > numa node0 (8GB local memory, 16 CPUs) > >> >> > numa node1 (8GB slow tier memory, no CPUs) > >> >> > > >> >> > Sequence: > >> >> > > >> >> > 1) echo 3 > /proc/sys/vm/drop_caches > >> >> > 2) To emulate the system with full of cold memory in local DRAM, run > >> >> > the following dummy program and never touch the region: > >> >> > > >> >> > mmap(0, 8 * 1024 * 1024 * 1024, PROT_READ | PROT_WRITE, > >> >> > MAP_ANONYMOUS | MAP_PRIVATE | MAP_POPULATE, -1, 0); > >> >> > > >> >> > 3) Run any memory intensive work e.g. XSBench. > >> >> > 4) Check if numa balancing is working e.i. promotion/demotion. > >> >> > 5) Iterate 1) ~ 4) until numa balancing stops. > >> >> > > >> >> > With this, you could see that promotion/demotion are not working because > >> >> > kswapd has stopped due to ->kswapd_failures >= MAX_RECLAIM_RETRIES. > >> >> > > >> >> > Interesting vmstat delta's differences between before and after are like: > >> >> > > >> >> > +-----------------------+-------------------------------+ > >> >> > | interesting vmstat | before | after | > >> >> > +-----------------------+-------------------------------+ > >> >> > | nr_inactive_anon | 321935 | 1636737 | > >> >> > | nr_active_anon | 1780700 | 465913 | > >> >> > | nr_inactive_file | 30425 | 35711 | > >> >> > | nr_active_file | 14961 | 8698 | > >> >> > | pgpromote_success | 356 | 1267785 | > >> >> > | pgpromote_candidate | 21953245 | 1745631 | > >> >> > | pgactivate | 1844523 | 3309867 | > >> >> > | pgdeactivate | 50634 | 1545041 | > >> >> > | pgfault | 31100294 | 6411036 | > >> >> > | pgdemote_kswapd | 30856 | 2267467 | > >> >> > | pgscan_kswapd | 1861981 | 7729231 | > >> >> > | pgscan_anon | 1822930 | 7667544 | > >> >> > | pgscan_file | 39051 | 61687 | > >> >> > | pgsteal_anon | 386 | 2227217 | > >> >> > | pgsteal_file | 30470 | 40250 | > >> >> > | pageoutrun | 30 | 457 | > >> >> > | numa_hint_faults | 27418279 | 2752289 | > >> >> > | numa_pages_migrated | 356 | 1267785 | > >> >> > +-----------------------+-------------------------------+ > >> >> > > >> >> > Signed-off-by: Byungchul Park > >> >> > --- > >> >> > mm/vmscan.c | 24 +++++++++++++++++++----- > >> >> > 1 file changed, 19 insertions(+), 5 deletions(-) > >> >> > > >> >> > diff --git a/mm/vmscan.c b/mm/vmscan.c > >> >> > index bba207f41b14..f7312d831fed 100644 > >> >> > --- a/mm/vmscan.c > >> >> > +++ b/mm/vmscan.c > >> >> > @@ -127,6 +127,9 @@ struct scan_control { > >> >> > /* One of the zones is ready for compaction */ > >> >> > unsigned int compaction_ready:1; > >> >> > > >> >> > + /* If the last try was reclaimable */ > >> >> > + unsigned int reclaimable:1; > >> >> > + > >> >> > /* There is easily reclaimable cold cache in the current node */ > >> >> > unsigned int cache_trim_mode:1; > >> >> > > >> >> > @@ -2266,9 +2269,14 @@ static void prepare_scan_control(pg_data_t *pgdat, struct scan_control *sc) > >> >> > * If we have plenty of inactive file pages that aren't > >> >> > * thrashing, try to reclaim those first before touching > >> >> > * anonymous pages. > >> >> > + * > >> >> > + * It doesn't make sense to keep cache_trim_mode on if the mode > >> >> > + * is not working while struggling against reclaim. So do not > >> >> > + * turn it on if so. Note the highest priority of kswapd is 1. > >> >> > */ > >> >> > file = lruvec_page_state(target_lruvec, NR_INACTIVE_FILE); > >> >> > - if (file >> sc->priority && !(sc->may_deactivate & DEACTIVATE_FILE)) > >> >> > + if (file >> sc->priority && !(sc->may_deactivate & DEACTIVATE_FILE) && > >> >> > + !(sc->cache_trim_mode && !sc->reclaimable && sc->priority <= 1)) > >> >> > sc->cache_trim_mode = 1; > >> >> > else > >> >> > sc->cache_trim_mode = 0; > >> > > >> > The overall goal makes sense to me. > >> > > >> > file >> priority is just a heuristic that there are enough potential > >> > candidate pages, not a guarantee that any forward progress will > >> > happen. So it makes sense to retry without before failing. > >> > > >> > The way you wrote this conditional kind of hurts my head, > >> > though. Please don't write negations of complex terms like this. > >> > > >> > It expands to this: > >> > > >> > !sc->cache_trim_mode || sc->reclaimable || sc->priority > 1 > >> > > >> > which I'm not sure makes sense. Surely it should be something like > >> > > >> > !sc->cache_trim_mode && sc->reclaimable && sc->priority > 1 > >> > > >> > instead? > >> > > >> > Also > >> > > >> > if (!sc->cache_trim_mode) > >> > sc->cache_trim_mode = 1 > >> > else > >> > sc->cache_trim_mode = 0 > >> > > >> > will toggle on every loop. So if direct reclaim runs through a > >> > zonelist, it'll cache trim every other numa node...? > >> > > >> >> > @@ -5862,7 +5870,6 @@ static void shrink_node(pg_data_t *pgdat, struct scan_control *sc) > >> >> > { > >> >> > unsigned long nr_reclaimed, nr_scanned, nr_node_reclaimed; > >> >> > struct lruvec *target_lruvec; > >> >> > - bool reclaimable = false; > >> >> > > >> >> > if (lru_gen_enabled() && root_reclaim(sc)) { > >> >> > lru_gen_shrink_node(pgdat, sc); > >> >> > @@ -5877,6 +5884,14 @@ static void shrink_node(pg_data_t *pgdat, struct scan_control *sc) > >> >> > nr_reclaimed = sc->nr_reclaimed; > >> >> > nr_scanned = sc->nr_scanned; > >> >> > > >> >> > + /* > >> >> > + * Reset to the default values at the start. > >> >> > + */ > >> >> > + if (sc->priority == DEF_PRIORITY) { > >> >> > + sc->reclaimable = 1; > >> >> > + sc->cache_trim_mode = 0; > >> >> > + } > >> >> > + > >> >> > prepare_scan_control(pgdat, sc); > >> >> > > >> >> > shrink_node_memcgs(pgdat, sc); > >> >> > @@ -5890,8 +5905,7 @@ static void shrink_node(pg_data_t *pgdat, struct scan_control *sc) > >> >> > vmpressure(sc->gfp_mask, sc->target_mem_cgroup, true, > >> >> > sc->nr_scanned - nr_scanned, nr_node_reclaimed); > >> >> > > >> >> > - if (nr_node_reclaimed) > >> >> > - reclaimable = true; > >> >> > + sc->reclaimable = !!nr_node_reclaimed; > >> > > >> > The scope of this doesn't quite make sense. If direct reclaim scans > >> > multiple nodes, reclaim failure on the first node would disable cache > >> > trim mode on the second node, which is totally unrelated. > >> > > >> > I think it needs separate paths for direct reclaim and kswapd. For > >> > direct reclaim, the retry should be before these similar retry catches > >> > in do_try_to_free_pages(), after all zones have been considered: > >> > > >> > /* > >> > * We make inactive:active ratio decisions based on the node's > >> > * composition of memory, but a restrictive reclaim_idx or a > >> > * memory.low cgroup setting can exempt large amounts of > >> > * memory from reclaim. Neither of which are very common, so > >> > * instead of doing costly eligibility calculations of the > >> > * entire cgroup subtree up front, we assume the estimates are > >> > * good, and retry with forcible deactivation if that fails. > >> > */ > >> > if (sc->skipped_deactivate) { > >> > sc->priority = initial_priority; > >> > sc->force_deactivate = 1; > >> > sc->skipped_deactivate = 0; > >> > goto retry; > >> > } > >> > > >> > /* Untapped cgroup reserves? Don't OOM, retry. */ > >> > if (sc->memcg_low_skipped) { > >> > sc->priority = initial_priority; > >> > sc->force_deactivate = 0; > >> > sc->memcg_low_reclaim = 1; > >> > sc->memcg_low_skipped = 0; > >> > goto retry; > >> > } > >> > >> In get_scan_count(), we have > >> > >> if (!sc->priority && swappiness) { > >> scan_balance = SCAN_EQUAL; > >> goto out; > >> } > > > > Even though this can mitigate the issue for direct reclaim, it's still > > suffering from the problem while direct reclaim goes from DEF_PRIORITY > > to 1. What we need is not a mitigation but making things right. > > Whether does it cause issue for you? IMHO, it's the first step to prove > this is a real problem. I'm not strongly arguing. It'd be still okay to fix the real problem that I faced with kswapd. Byungchul > -- > Best Regards, > Huang, Ying > > > Thoughts? > > > > Byungchul > > > >> So, we don't really need the heuristics in direct reclaim path. So, one > >> choice is to constrain this in kswapd reclaim only. > >> > >> -- > >> Best Regards, > >> Huang, Ying > >> > >> > >> > and for kswapd it looks like it should be in balance_pgdat(), after > >> > the priority loop, before increasing kswapd_failures. > >> > > >> > Instead of sc->reclaimable, which is very broad, it would be better to > >> > call it sc->may_cache_trim_mode. This is in line with a bunch of other > >> > such mechanisms in scan_control.