From patchwork Wed Sep 20 19:02:39 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kairui Song X-Patchwork-Id: 13393223 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 14435C04FEB for ; Wed, 20 Sep 2023 19:03:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A04FA6B0199; Wed, 20 Sep 2023 15:03:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B57A6B019A; Wed, 20 Sep 2023 15:03:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82F3D6B019B; Wed, 20 Sep 2023 15:03:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 705E96B0199 for ; Wed, 20 Sep 2023 15:03:08 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4145B12076A for ; Wed, 20 Sep 2023 19:03:08 +0000 (UTC) X-FDA: 81257898456.25.51E5F83 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf25.hostedemail.com (Postfix) with ESMTP id 13380A002D for ; Wed, 20 Sep 2023 19:03:05 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VCW1QMKu; spf=pass (imf25.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695236586; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ouvC9AOz3I+aujxy3BgYZwvGJPKjc3/8uuxzUuwqOFg=; b=UMg8PLJkdj5hIHn8WQAD2nmjztIaM/FiKJXl+dBmdIIXVEj05P/TeUFaVxixmrA1l+NeUm 5XZoT9t1tHCfDFCGF8rUImSTWjOENXAX3Siz2gfht/BpE47/HYzSAw7D1QrNSa5i0iIQNl y0saOGnINRWdjhhm/NqUcaWZCaaO/EY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695236586; a=rsa-sha256; cv=none; b=HGOlPIeK8eTFgzS/RgXhgTSbNmNayofrLbwrFMCj4ozUZVa2Mnd+8ciytxoHnrHbRuslzB 0xdj2zXeSpla5z4JHUFNbxQBpnfMrqXMdzKFeBD7ubpuvXeUwjb9Z0hs1KlswoGdQhhIXQ tOJVDJda7uaf3hjS4P52Jnh3jwsLU9I= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VCW1QMKu; spf=pass (imf25.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-690bd8f89baso106540b3a.2 for ; Wed, 20 Sep 2023 12:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695236584; x=1695841384; darn=kvack.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=ouvC9AOz3I+aujxy3BgYZwvGJPKjc3/8uuxzUuwqOFg=; b=VCW1QMKupfGDB7mv4E9vY0gYpYwmMr1bOP97xPm2lKOymTftwPA4lNAm/Iy+R9PqHB yysNO8s0bin6vZgcUuTCqYIEnyOjNp9X7S9RDSSK4nxT+uVtm6qgTIrO9UYml6ZzPKno lNBx+u9KIFrK3kNX1qqTFOaepcNaLewpJ0mZ3vrmJCUE3OQoS51ZhlVK5VGilDw1BWMH liElY2v/aj+DIDMlbF5k/Ks+SpWTgJZelt3kj7S+LDGUiItsQVRYeh/LbK+ZWAA1yEbG XV8UZOHV5ycoezmZu0tmuvySnPqoSA3se5eYioyETLZU1wJg6VivqnsONsAeZVXPM6Xt ADDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695236584; x=1695841384; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ouvC9AOz3I+aujxy3BgYZwvGJPKjc3/8uuxzUuwqOFg=; b=AN/vh8OnWKPP27x79R0p1TysuKI/ZGR9lteIsZdk4aij0Yc1LC6eKKciyWCQTN+w3b AMo+LihokSbxMN+rUcYfeCP+NTgZ1TyKHZ+nw20Jpe17C9UuU4Z2yqdApgu7uwjGut1o hW/gFP/2meuFZTVI7q9KACTF/VuduvIOgkdx2sREdIQWL4ww8sj2FjL9PudExGwsrIO2 T/bJBG6sYLpf1htKGgmR9A7JM1qFHdM/7QlmHrznRLuSNHuKdYowj4d2f0NBppPYNiOc LJYYwZ0hYMybvRbcdCCwkt4nOk6WWT3Xk7KdzbmC6Q6emngCGhGEt0kiG4z8MEEBgOZO be+A== X-Gm-Message-State: AOJu0YwGPDZmeqg9BvBCdKFo6psIbB0rClSWNIlqyMsDyjm5ktxZpuiJ UB9vMKoLMa+ELnU+P1wxPwuESfx1raAcIGjMkGA= X-Google-Smtp-Source: AGHT+IHpkXwDW7wLHkw9/gwS4e48YtJ5+qZf0n+vVOPD7mH5dU+NucT1NkWU/2VMS3T4gOkfxVuwEg== X-Received: by 2002:a05:6a20:8402:b0:153:78c1:c40f with SMTP id c2-20020a056a20840200b0015378c1c40fmr4054957pzd.15.1695236583894; Wed, 20 Sep 2023 12:03:03 -0700 (PDT) Received: from KASONG-MB2.tencent.com ([124.127.145.18]) by smtp.gmail.com with ESMTPSA id m5-20020aa78a05000000b006871fdde2c7sm423935pfa.110.2023.09.20.12.03.00 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 20 Sep 2023 12:03:03 -0700 (PDT) From: Kairui Song To: linux-mm@kvack.org Cc: Andrew Morton , Yu Zhao , Roman Gushchin , Johannes Weiner , Michal Hocko , Hugh Dickins , Nhat Pham , Yuanchu Xie , Kalesh Singh , Suren Baghdasaryan , "T . J . Mercier" , linux-kernel@vger.kernel.org, Kairui Song Subject: [RFC PATCH v3 1/6] workingset: simplify and use a more intuitive model Date: Thu, 21 Sep 2023 03:02:39 +0800 Message-ID: <20230920190244.16839-2-ryncsn@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230920190244.16839-1-ryncsn@gmail.com> References: <20230920190244.16839-1-ryncsn@gmail.com> Reply-To: Kairui Song MIME-Version: 1.0 X-Rspamd-Queue-Id: 13380A002D X-Rspam-User: X-Stat-Signature: p16e18pino6quwsxsno4fx4z394hqzgb X-Rspamd-Server: rspam03 X-HE-Tag: 1695236585-555899 X-HE-Meta: U2FsdGVkX1821vrZj9irG7VzYBorhb/0B2MUQKfM4ujQnz9XPlW2rjvn0n2OYV/vusaFjHQTVgNgrJsHwWOaM8FZ9sy198wNjRVsd3VD23G+3CIUhD5l2CaQM0QjjFSWycPpWSILMxFnWmXQx6HXDIQxTO27o4c/214D1pDKkLkejD0/zXGllnsPJJBJY/C9BD/1xBtAn5hOp2bIAVe1YfxBmRIWzy7DteAfFD6ZCqtSXJraM8iexoirhCBJDf9Dfej7cHn8naUEDr08464lCY9hTvojDoUyXP7TDBqIgLUoK3J9J4BP9PfgUVwwtOI9FPSZ0r0yNsXg6SxW7XOh8leQ6kqGEXU//y1ndGQG+7EF3aQjccYaBXb/P4ycFHiR5vmjRo1wXoxe2y78mItnDmtOUwdilpfQhZWt9OoSMeIjanm4oPdBhlZTNWuulpVikK2CUlu3/M+4Q8evEuRdycuENqosbewgADeEmAqhsf4ex64gLEbasASeZKhZZvadWmDg/dFNccs3KkQisNUj/1FjoCnCKWEGvN2SyGlVXm8PEGDUDMrcAfjq9qfKSn62aVpCNlnR6ohSAfmqe6GvELf75e6qjQqz0JFmFfsdJZsCup1zKeKnf41UQjTqISGhj0sksbwbl2IIfNI3vgJn9WYe9oLj09g7oOzm3S1z5SkEpvIf2tonmsagp4B69Nkez++jmbs85xGWkpjQOTbpevSseEyrmoaIs9LDV7Hq/zvv4KYENH1YDdw6kgBQM66vmZXW510ZPxfoA7PdOiVLSLoEXZCGQABrrIXMhVfoSgFP2ajAnRJ9s2yDrN83eP9CodnjT8YrigtTeqLLFf6hlm2B4EFNy3UNm0+NxmyL+lv5TdiriA16I1ycxtDjFtEE2QDlCN1AnncCcNJO1UQQ0tdKChkT41FyQkv0VIoLg+hZzmBtePS80KBZEfg5CAuOWHHrjKEEgZJ27i5qJL1 2xKToJ7K UF8wLU8/lt+xgj6tKJUXU2jKMUqzvD4UPgo7gso1704MPi7dCg/qFBnAxyLZXXHypX8K8VECg0DlJBJCjUlR4b2+BI/B40Rb6kFOStqpdzWJrXCxy5RxrGbGUCrstb0Pq87paFx68npKuBEVDkw1PUYyTmJNrmVxLu9iGN/pL/mutSyEvENkEXYVSirz/dKjQaL/mKaWV+yPY41+qH52d+Xv5cYipmNziMuhpgvNewN5fOyYUc52I5n99a3O/2gSxNjYXbLr40fxa1QbDdceSBHd/ojr3V7MVTFrEFd6ivGOPJ9K9hR/gPTlC3d8/MrFGAwbAuaSSgaUTkNPdLZQKSnV88B19G4JYlqYhoKpvtZRmhvMy67BBKor4lkvUTgY7DGtbXz9xBjGMhs959tLyxphthmrG4EjI+01ijT8BYBf9laDDU0LTS8lqtFmgHIBzZ6kkwKR5SIKo+t9YfIuGy4v7p6AevuENqTmEhUaC9Xh78LbZmJ7rI/z55GN9x7jaJLa7SZPVw0soVfVrSOkbbFxM05gIIXibKvcXF//wYhK1ZLSoXMn39ZjBYkqAOkw3MEXVDKeMJ3Hq00UFfv3gczb/NQC/urokQ2WEyVQZd87HuBWVgykUVu6TR0Bhcn1KHFgL 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: From: Kairui Song This basically removed workingset_activation and reduced calls to workingset_age_nonresident. The idea behind this change is a new way to calculate the refault distance and prepare for adapting refault distance based re-activation for multi-gen LRU. Currently, refault distance re-activation is based on two assumptions: 1. Activation of an inactive page will left-shift LRU pages (considering LRU starts from right). 2. Eviction of an inactive page will left-shift LRU pages. Assumption 2 is correct, but assumption 1 is not always true, an activated page could be anywhere in the LRU list (through mark_page_accessed), it only left-shift the pages on its right. And besides, one page can get activate/deactivated for multiple times. And multi-gen LRU doesn't fit with this model well, pages are getting aged and activated constantly as the generation sliding window slides. So instead we introduce a simpler idea here: Just presume the evicted pages are still in memory, each has an eviction sequence like before. Let the `nonresistence_age` still be NA and get increased for each eviction, so we get a "Shadow LRU" here of one evicted page: Let SP = ((NA's reading @ current) - (NA's reading @ eviction)) +-memory available to cache-+ | | +-------------------------+===============+===========+ | * shadows O O O | INACTIVE | ACTIVE | +-+-----------------------+===============+===========+ | | +-----------------------+ | SP fault page O -> Hole left by previously faulted in pages * -> The page corresponding to SP It can be easily seen that SP stands for how far the current workflow could push a page out of available memory. Since all evicted page was once head of INACTIVE list, the page could have such an access distance: SP + NR_INACTIVE It *may* get re-activated before getting evicted again if: SP + NR_INACTIVE < NR_INACTIVE + NR_ACTIVE Which can be simplified to: SP < NR_ACTIVE Then the page is worth getting re-activated to start from ACTIVE part, since the access distance is shorter than the total memory to make it stay. And since this is only an estimation, based on several hypotheses, and it could break the ability of LRU to distinguish a workingset out of caches, so throttle this by two factors: 1. Notice previously re-faulted in pages may leave "holes" on the shadow part of LRU, that part is left unhandled on purpose to decrease re-activate rate for pages that have a large SP value (the larger SP value a page has, the more likely it will be affected by such holes). 2. When the ACTIVE part of LRU is long enough, chanllaging ACTIVE pages by re-activating a one-time faulted previously INACTIVE page may not be a good idea, so throttle the re-activation when ACTIVE > INACTIVE by comparing with INACTIVE instead. Another effect of the refault activation worth noticing is that, by throttling reactivation when ACTIVE part is high, this refault distance based re-activation can help hold a portion of the caches in memory instead of letting cached get evicted permutably when the cache size is larger than total memory, and hotness is similar among all cache pages. That's because the established workingset (ACTIVE part) will tend to stay since we throttled reactivation, until the workingset itself start to stall. This is actually similar with the algoritm before, which introduce such effect by increasing nonresistence_age in many call paths, trottled the reactivation when activition/reactivation is massively happenning. Combined all above, we have: Upon refault, if any of following conditions is met, mark page as active: - If ACTIVE LRU is low (NR_ACTIVE < NR_INACTIVE), check if: SP < NR_ACTIVE - If ACTIVE LRU is high (NR_ACTIVE >= NR_INACTIVE), check if: SP < NR_INACTIVE Code-wise, this is simpler than before since no longer need to do lruvec statistic update when activating a page, and so far, a few benchmarks shows a similar or better result. And when combined with multi-gen LRU (in later commits) it shows a measurable performance gain for some workloads. Using memtier and fio test from commit ac35a4902374 but scaled down to fit in my test environment, and some other test results: memtier test (with 16G ramdisk as swap and 4G memcg limit on an i7-9700): memcached -u nobody -m 16384 -s /tmp/memcached.socket \ -a 0766 -t 12 -B binary & memtier_benchmark -S /tmp/memcached.socket -P memcache_binary -n allkeys\ --key-minimum=1 --key-maximum=32000000 --key-pattern=P:P -c 1 \ -t 12 --ratio 1:0 --pipeline 8 -d 2000 -x 6 fio test 1 (with 16G ramdisk on 28G VM on an i7-9700): fio -name=refault --numjobs=12 --directory=/mnt --size=1024m \ --buffered=1 --ioengine=io_uring --iodepth=128 \ --iodepth_batch_submit=32 --iodepth_batch_complete=32 \ --rw=randread --random_distribution=random --norandommap \ --time_based --ramp_time=5m --runtime=5m --group_reporting fio test 2 (with 16G ramdisk on 28G VM on an i7-9700): fio -name=mglru --numjobs=10 --directory=/mnt --size=1536m \ --buffered=1 --ioengine=io_uring --iodepth=128 \ --iodepth_batch_submit=32 --iodepth_batch_complete=32 \ --rw=randread --random_distribution=zipf:1.2 --norandommap \ --time_based --ramp_time=10m --runtime=5m --group_reporting mysql (using oltp_read_only from sysbench, with 12G of buffer pool in a 10G memcg): sysbench /usr/share/sysbench/oltp_read_only.lua \ --tables=36 --table-size=2000000 --threads=12 --time=1800 kernel build test done with 3G memcg limit on an i7-9700. Before (Average of 6 test run): fio: IOPS=5125.5k fio2: IOPS=7291.16k memcached: 57600.926 ops/s mysql: 6491.5 tps kernel-build: 1817.13499 seconds After (Average of 6 test run): fio: IOPS=5137.5k fio2: IOPS=7300.67k memcached: 57878.422 ops/s mysql: 6491.1 tps kernel-build: 1813.66231 seconds Signed-off-by: Kairui Song --- include/linux/swap.h | 2 - mm/swap.c | 1 - mm/vmscan.c | 2 - mm/workingset.c | 155 ++++++++++++++++++------------------------- 4 files changed, 64 insertions(+), 96 deletions(-) diff --git a/include/linux/swap.h b/include/linux/swap.h index 493487ed7c38..ca51d79842b7 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -344,10 +344,8 @@ static inline swp_entry_t page_swap_entry(struct page *page) /* linux/mm/workingset.c */ bool workingset_test_recent(void *shadow, bool file, bool *workingset); -void workingset_age_nonresident(struct lruvec *lruvec, unsigned long nr_pages); void *workingset_eviction(struct folio *folio, struct mem_cgroup *target_memcg); void workingset_refault(struct folio *folio, void *shadow); -void workingset_activation(struct folio *folio); /* Only track the nodes of mappings with shadow entries */ void workingset_update_node(struct xa_node *node); diff --git a/mm/swap.c b/mm/swap.c index cd8f0150ba3a..685b446fd4f9 100644 --- a/mm/swap.c +++ b/mm/swap.c @@ -482,7 +482,6 @@ void folio_mark_accessed(struct folio *folio) else __lru_cache_activate_folio(folio); folio_clear_referenced(folio); - workingset_activation(folio); } if (folio_test_idle(folio)) folio_clear_idle(folio); diff --git a/mm/vmscan.c b/mm/vmscan.c index 6f13394b112e..3f4de75e5186 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2539,8 +2539,6 @@ static unsigned int move_folios_to_lru(struct lruvec *lruvec, lruvec_add_folio(lruvec, folio); nr_pages = folio_nr_pages(folio); nr_moved += nr_pages; - if (folio_test_active(folio)) - workingset_age_nonresident(lruvec, nr_pages); } /* diff --git a/mm/workingset.c b/mm/workingset.c index da58a26d0d4d..8613945fc66e 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -64,74 +64,64 @@ * thrashing on the inactive list, after which refaulting pages can be * activated optimistically to compete with the existing active pages. * - * Approximating inactive page access frequency - Observations: + * For such approximation, we introduce a counter `nonresistence_age` (NA) + * here. This counter increases each time a page is evicted, and each evicted + * page will have a shadow that stores the counter reading at the eviction + * time as a timestamp. So when an evicted page was faulted again, we have: * - * 1. When a page is accessed for the first time, it is added to the - * head of the inactive list, slides every existing inactive page - * towards the tail by one slot, and pushes the current tail page - * out of memory. + * Let SP = ((NA's reading @ current) - (NA's reading @ eviction)) * - * 2. When a page is accessed for the second time, it is promoted to - * the active list, shrinking the inactive list by one slot. This - * also slides all inactive pages that were faulted into the cache - * more recently than the activated page towards the tail of the - * inactive list. + * +-memory available to cache-+ + * | | + * +-------------------------+===============+===========+ + * | * shadows O O O | INACTIVE | ACTIVE | + * +-+-----------------------+===============+===========+ + * | | + * +-----------------------+ + * | SP + * fault page O -> Hole left by previously faulted in pages + * * -> The page corresponding to SP * - * Thus: + * Here SP can stands for how far the current workflow could push a page + * out of available memory. Since all evicted page was once head of + * INACTIVE list, the page could have such an access distance of: * - * 1. The sum of evictions and activations between any two points in - * time indicate the minimum number of inactive pages accessed in - * between. + * SP + NR_INACTIVE * - * 2. Moving one inactive page N page slots towards the tail of the - * list requires at least N inactive page accesses. + * So if: * - * Combining these: + * SP + NR_INACTIVE < NR_INACTIVE + NR_ACTIVE * - * 1. When a page is finally evicted from memory, the number of - * inactive pages accessed while the page was in cache is at least - * the number of page slots on the inactive list. + * Which can be simplified to: * - * 2. In addition, measuring the sum of evictions and activations (E) - * at the time of a page's eviction, and comparing it to another - * reading (R) at the time the page faults back into memory tells - * the minimum number of accesses while the page was not cached. - * This is called the refault distance. + * SP < NR_ACTIVE * - * Because the first access of the page was the fault and the second - * access the refault, we combine the in-cache distance with the - * out-of-cache distance to get the complete minimum access distance - * of this page: + * Then the page is worth getting re-activated to start from ACTIVE part, + * since the access distance is shorter than total memory to make it stay. * - * NR_inactive + (R - E) + * And since this is only an estimation, based on several hypotheses, and + * it could break the ability of LRU to distinguish a workingset out of + * caches, so throttle this by two factors: * - * And knowing the minimum access distance of a page, we can easily - * tell if the page would be able to stay in cache assuming all page - * slots in the cache were available: + * 1. Notice that re-faulted in pages may leave "holes" on the shadow + * part of LRU, that part is left unhandled on purpose to decrease + * re-activate rate for pages that have a large SP value (the larger + * SP value a page have, the more likely it will be affected by such + * holes). + * 2. When the ACTIVE part of LRU is long enough, challenging ACTIVE pages + * by re-activating a one-time faulted previously INACTIVE page may not + * be a good idea, so throttle the re-activation when ACTIVE > INACTIVE + * by comparing with INACTIVE instead. * - * NR_inactive + (R - E) <= NR_inactive + NR_active + * Combined all above, we have: + * Upon refault, if any of the following conditions is met, mark the page + * as active: * - * If we have swap we should consider about NR_inactive_anon and - * NR_active_anon, so for page cache and anonymous respectively: - * - * NR_inactive_file + (R - E) <= NR_inactive_file + NR_active_file - * + NR_inactive_anon + NR_active_anon - * - * NR_inactive_anon + (R - E) <= NR_inactive_anon + NR_active_anon - * + NR_inactive_file + NR_active_file - * - * Which can be further simplified to: - * - * (R - E) <= NR_active_file + NR_inactive_anon + NR_active_anon - * - * (R - E) <= NR_active_anon + NR_inactive_file + NR_active_file - * - * Put into words, the refault distance (out-of-cache) can be seen as - * a deficit in inactive list space (in-cache). If the inactive list - * had (R - E) more page slots, the page would not have been evicted - * in between accesses, but activated instead. And on a full system, - * the only thing eating into inactive list space is active pages. + * - If ACTIVE LRU is low (NR_ACTIVE < NR_INACTIVE), check if: + * SP < NR_ACTIVE * + * - If ACTIVE LRU is high (NR_ACTIVE >= NR_INACTIVE), check if: + * SP < NR_INACTIVE * * Refaulting inactive pages * @@ -419,8 +409,10 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset) struct mem_cgroup *eviction_memcg; struct lruvec *eviction_lruvec; unsigned long refault_distance; - unsigned long workingset_size; + unsigned long inactive_file; + unsigned long inactive_anon; unsigned long refault; + unsigned long active; int memcgid; struct pglist_data *pgdat; unsigned long eviction; @@ -479,21 +471,27 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset) * workingset competition needs to consider anon or not depends * on having free swap space. */ - workingset_size = lruvec_page_state(eviction_lruvec, NR_ACTIVE_FILE); - if (!file) { - workingset_size += lruvec_page_state(eviction_lruvec, - NR_INACTIVE_FILE); - } + active = lruvec_page_state(eviction_lruvec, NR_ACTIVE_FILE); + inactive_file = lruvec_page_state(eviction_lruvec, NR_INACTIVE_FILE); + if (mem_cgroup_get_nr_swap_pages(eviction_memcg) > 0) { - workingset_size += lruvec_page_state(eviction_lruvec, + active += lruvec_page_state(eviction_lruvec, NR_ACTIVE_ANON); - if (file) { - workingset_size += lruvec_page_state(eviction_lruvec, - NR_INACTIVE_ANON); - } + inactive_anon = lruvec_page_state(eviction_lruvec, + NR_INACTIVE_ANON); + } else { + inactive_anon = 0; } - return refault_distance <= workingset_size; + /* + * When there are already enough active pages, be less aggressive + * on reactivating pages, challenge an large set of established + * active pages with one time refaulted page may not be a good idea. + */ + if (active >= inactive_anon + inactive_file) + return refault_distance < inactive_anon + inactive_file; + else + return refault_distance < active + (file ? inactive_anon : inactive_file); } /** @@ -543,7 +541,6 @@ void workingset_refault(struct folio *folio, void *shadow) goto out; folio_set_active(folio); - workingset_age_nonresident(lruvec, nr); mod_lruvec_state(lruvec, WORKINGSET_ACTIVATE_BASE + file, nr); /* Folio was active prior to eviction */ @@ -560,30 +557,6 @@ void workingset_refault(struct folio *folio, void *shadow) rcu_read_unlock(); } -/** - * workingset_activation - note a page activation - * @folio: Folio that is being activated. - */ -void workingset_activation(struct folio *folio) -{ - struct mem_cgroup *memcg; - - rcu_read_lock(); - /* - * Filter non-memcg pages here, e.g. unmap can call - * mark_page_accessed() on VDSO pages. - * - * XXX: See workingset_refault() - this should return - * root_mem_cgroup even for !CONFIG_MEMCG. - */ - memcg = folio_memcg_rcu(folio); - if (!mem_cgroup_disabled() && !memcg) - goto out; - workingset_age_nonresident(folio_lruvec(folio), folio_nr_pages(folio)); -out: - rcu_read_unlock(); -} - /* * Shadow entries reflect the share of the working set that does not * fit into memory, so their number depends on the access pattern of From patchwork Wed Sep 20 19:02:40 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kairui Song X-Patchwork-Id: 13393224 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 BACC0C04FED for ; Wed, 20 Sep 2023 19:03:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D6E06B019B; Wed, 20 Sep 2023 15:03:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4852A6B019D; Wed, 20 Sep 2023 15:03:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FFA66B019C; Wed, 20 Sep 2023 15:03:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1C7CD6B019A for ; Wed, 20 Sep 2023 15:03:12 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B7F1F40A95 for ; Wed, 20 Sep 2023 19:03:11 +0000 (UTC) X-FDA: 81257898582.09.D217A44 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf27.hostedemail.com (Postfix) with ESMTP id D12AB40030 for ; Wed, 20 Sep 2023 19:03:09 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lZeEgruS; spf=pass (imf27.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.179 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695236589; a=rsa-sha256; cv=none; b=COC2moICIiMRHqQenK0K2uuaPGJw8U4My9DEfXFl7cb3jnhRxN83Ls3WnAQg4Hp51mxs+4 xso2XfOq8aWkbmPZtuemS/8yg+0Q/P5+12mYnb6M8NLz8+6g+s1mH2ZzfBlg+cmVoj7YgY gWcBchHQuvQZrnTvwZKGB+mzDzG4Pi0= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lZeEgruS; spf=pass (imf27.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.179 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695236589; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DHOkw8Z/lNeirjsVQWHKGHEmHDrpMBtO7DHMUSjWf4M=; b=oukbwGw1RDlTmzyGle9Q+tG5O2e5+PPKlx73IMIiLb5iigDSMDvgV8cirgK651cacnDbIy Sv8Sn/Ywwe/cCqhYmqnQUjhlenwgGIVDbsM5zVGiDIlai9B6obXggXuK++gzRiZIIDbU6N h5DrkRlaw5Z0f+scvUr2zpaurWAsZ0I= Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-69101022969so99962b3a.3 for ; Wed, 20 Sep 2023 12:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695236588; x=1695841388; darn=kvack.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=DHOkw8Z/lNeirjsVQWHKGHEmHDrpMBtO7DHMUSjWf4M=; b=lZeEgruS3rNYs3tb8AFayOL8OMACgCcNQTpKFpfVCMvxEUBmfxlKWOl+qFF6Jnhwvh i8hgC3zic0dkOVCLojnsdKr0sto+FeqjQ3BHGb/9ornLVc20tF/5zSw29UJI/7PqpJM4 BI5wJf6K5UdM6L04SvPmRWLLheKKJtT2h8rnJOyakRn2jSC2+L7aCu+pP5XvacTMPjWA F8FogA2DTeSszsl1RQ9HKPkDMt2HxwGrptNZD8gsVm9vMEzfK4H7RoRlzlw9pfp1Ui9m BG67qkmI2Td1eRyKR8timCqp27N9cO4aVGwwIRc/xYzge2kEKZ+bkNgYUz1HgI4hNPAS DOJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695236588; x=1695841388; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DHOkw8Z/lNeirjsVQWHKGHEmHDrpMBtO7DHMUSjWf4M=; b=BgHK/mTC2gRymlBtqoDZiluIEt+i7y8fKyOYZfPKUGzyXgKzo5XCKHyww4UPvd3rfN YzkYnCyss2kwBqqOU4Rehi36KjB7+et6b07fg02brVUlPe4uOyHzMaLi5Wax/uehsw5X CsmuJmAxco8bgUzz6hjvIPmCfQMVVyvtCIPBfgbhb1XDzcLA1rIELdjZoNoWT5BLKqqG RA216gHBYGXgReSBGRtUXHu27nNE0rJxrXFulhjdssMn51ktY8U5rD96qBNAuqYbU9k1 /HyPWZR7imIPefh0Mp/d0nxV+7IFWKY6Tc5mqntpxm5eigjrwNAG6vZIaunjvD6Pl7Ar OmBA== X-Gm-Message-State: AOJu0YxFGFnyyvTR8sytO9YECFBf+0Gul4aTtCJG+8ZGSL62l72QuZSb S7ck22qtezxCi/MuaT4S19E2XWWo9Kw7NWjBAZ0= X-Google-Smtp-Source: AGHT+IELrwFtAaNAZSj3RuUKBX/6bRnBeBoGpeeG0jWHkgt6ISLm+F8uT2D8srjZchaOyGv6pWaVgg== X-Received: by 2002:a05:6a20:8e1f:b0:137:23a2:2b3c with SMTP id y31-20020a056a208e1f00b0013723a22b3cmr3637857pzj.49.1695236587894; Wed, 20 Sep 2023 12:03:07 -0700 (PDT) Received: from KASONG-MB2.tencent.com ([124.127.145.18]) by smtp.gmail.com with ESMTPSA id m5-20020aa78a05000000b006871fdde2c7sm423935pfa.110.2023.09.20.12.03.04 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 20 Sep 2023 12:03:07 -0700 (PDT) From: Kairui Song To: linux-mm@kvack.org Cc: Andrew Morton , Yu Zhao , Roman Gushchin , Johannes Weiner , Michal Hocko , Hugh Dickins , Nhat Pham , Yuanchu Xie , Kalesh Singh , Suren Baghdasaryan , "T . J . Mercier" , linux-kernel@vger.kernel.org, Kairui Song Subject: [RFC PATCH v3 2/6] workingset: move refault distance checking into to a helper Date: Thu, 21 Sep 2023 03:02:40 +0800 Message-ID: <20230920190244.16839-3-ryncsn@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230920190244.16839-1-ryncsn@gmail.com> References: <20230920190244.16839-1-ryncsn@gmail.com> Reply-To: Kairui Song MIME-Version: 1.0 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D12AB40030 X-Stat-Signature: 1isit6qgejbm83adnkpkcpgiaoqqtdjz X-Rspam-User: X-HE-Tag: 1695236589-785163 X-HE-Meta: U2FsdGVkX1+CSbtZhyk72RwGHkvpg6jrqFlUIempwPOpiVhxTbLHOPEi10ACvzqYrehauQN/wyWOChW0CcocaW2eF5kV+cGGbY+U7OW9ByL0T9fP08yLTd50qH/u3elmASdwHyE/MU9BeYIBBqWRP1KnbAgH/pNgaNkCWppJzWqQYu3nRShpTq9ioFoghYbcRoV4xtqZa1KBsfAZnU+c+Od/bqs7B7VbquUcZdsN3DlERi4iFIby+0XFbO2ziGottRqs6FuZGW5f5TPymMgpAiA7h/6YG667pVWbdLegkC/iKkgQgZwP2D3JPBu+GvozzFEclDMw5sRkwcw5QvPQSp9IpO2GOYGzYakehPah36POBTkgTgdL/OT0bsKKdNPldYe8tX+jtrN9Vof0gDUHYxIeidPO9EB1hET2Wfi/iuKOJ8W1L74xYXVl+C7OgHhxoZW2tdvdJQziFp2UBsjUAlv0sWmhFykQjmCqRQ9zrzU8t1zKUzadVsCXIs0hkCjixZO0OgZfohwe9GnU9UvVloNd77kfwQpm7ZzLOfRVihYFiQblRxTHL4HhZeoY6o2tCmUuR/VETQG+ApTTJmwgkx5alL0nWbg/XXOYL4oUnrubGNo3Yb9UFJHt4fKFurGVuUmS8O/1vjkmoXwo0AurdzOE/YqZF2FNf7Xlf3hp+I1bXRl2X0oL1dxtNTF2t1mupw750HM5cAkCLADuzlHPT0aafq+/GPw9jniHwGtgdYGIUwL9X5xYVYkVhjQsiZoVqY1Hkq5Nv3wEV53EskqgXtuH5ptAAdBUjq4S16meAdK9ThjNfaw8aJGeLNPVK1+R0dRkPqWfDw1egvhWylpw+eHwN8PbVBhZCSccauL/6HlSQrWmKsEDYptKt65bOIUZ7M/KLBAnJix/kvmaDJsLbehmDDcdb6SmbhMh8Ie8rYKmFLpHCBaKuRtV/xZmvMA9d7begln2KD5N442torq eiJb26do 1mOvEeuL34LcZFAxeDI/X6T0BwLfBPHaZ0vdbGDjuClbKjsUjuzoX00LfgGxCPkAioyC0pIyapr5tWOOV29FpJOzULnF2juJgaLwFbRCnhgPql4Gwy39c5xw9VCzUE32FaZTjayGkibThsTjAY1iXxJ74ZEWjEUXnTalZfykwvM/ubDwD5Lwmxmj5x15uoTa2+CgQSo6/4NDUZYhwrGwSerj4JfJjh+u69Des+GpbW3RQwgignRorjsYgQLWaavHjrDg7oiozklp/30cdFhRmINu8qfOQINxHnTkAvUg1Rwkx4P2syL/jlVEVEmEdWhLRv6nbs+Kofzlz2hbV8qpUq8tNqW5XH2BhPyagYi3z2CAzckQ2o+n+D4cL16zsaQCp/1Q+mPvKz/loXbpbHjeVueuB7qvK/PipeeSyJZBKyu7qWeiUbLxCY08Slp4jgEnovy2eEzxaIKD9+Z5TrdUDUNb7BPGojjihUMptAHc0tMsbLyPhciRI5s8xfj3sFRs4i/R7QqNhs/0k6rqEqZ7cbQbHtCwAiEblLy+VBTukTSdXsSWcUY7lqL3BWiXUyo65n2NffbUQgGTVWHXiGEkKP/rvQPCEgH0+43OwCbl44oDG315klszm/883OC9gzLc84ZF0 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: From: Kairui Song There isn't any feature change, just move the refault distance checking logic into a standalone helper so it can be reused later. Signed-off-by: Kairui Song --- mm/workingset.c | 137 ++++++++++++++++++++++++++++-------------------- 1 file changed, 79 insertions(+), 58 deletions(-) diff --git a/mm/workingset.c b/mm/workingset.c index 8613945fc66e..b0704cbfc667 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -170,9 +170,10 @@ */ #define WORKINGSET_SHIFT 1 -#define EVICTION_SHIFT ((BITS_PER_LONG - BITS_PER_XA_VALUE) + \ +#define EVICTION_SHIFT ((BITS_PER_LONG - BITS_PER_XA_VALUE) + \ WORKINGSET_SHIFT + NODES_SHIFT + \ MEM_CGROUP_ID_SHIFT) +#define EVICTION_BITS (BITS_PER_LONG - (EVICTION_SHIFT)) #define EVICTION_MASK (~0UL >> EVICTION_SHIFT) /* @@ -216,6 +217,79 @@ static void unpack_shadow(void *shadow, int *memcgidp, pg_data_t **pgdat, *workingsetp = workingset; } +/* + * Get the refault distance timestamp reading at eviction time. + */ +static inline unsigned long lru_eviction(struct lruvec *lruvec, + int bits, int bucket_order) +{ + unsigned long eviction = atomic_long_read(&lruvec->nonresident_age); + + eviction >>= bucket_order; + eviction &= ~0UL >> (BITS_PER_LONG - bits); + + return eviction; +} + +/* + * Calculate and test refault distance. + */ +static inline bool lru_test_refault(struct mem_cgroup *memcg, + struct lruvec *lruvec, + unsigned long eviction, bool file, + int bits, int bucket_order) +{ + unsigned long refault, distance; + unsigned long active, inactive_file, inactive_anon; + + eviction <<= bucket_order; + refault = atomic_long_read(&lruvec->nonresident_age); + + /* + * The unsigned subtraction here gives an accurate distance + * across nonresident_age overflows in most cases. There is a + * special case: usually, shadow entries have a short lifetime + * and are either refaulted or reclaimed along with the inode + * before they get too old. But it is not impossible for the + * nonresident_age to lap a shadow entry in the field, which + * can then result in a false small refault distance, leading + * to a false activation should this old entry actually + * refault again. However, earlier kernels used to deactivate + * unconditionally with *every* reclaim invocation for the + * longest time, so the occasional inappropriate activation + * leading to pressure on the active list is not a problem. + */ + distance = (refault - eviction) & (~0UL >> (BITS_PER_LONG - bits)); + + /* + * Compare the distance to the existing workingset size. We + * don't activate pages that couldn't stay resident even if + * all the memory was available to the workingset. Whether + * workingset competition needs to consider anon or not depends + * on having free swap space. + */ + active = lruvec_page_state(lruvec, NR_ACTIVE_FILE); + inactive_file = lruvec_page_state(lruvec, NR_INACTIVE_FILE); + + if (mem_cgroup_get_nr_swap_pages(memcg) > 0) { + active += lruvec_page_state(lruvec, NR_ACTIVE_ANON); + inactive_anon = lruvec_page_state(lruvec, NR_INACTIVE_ANON); + } else { + inactive_anon = 0; + } + + /* + * When there are already enough active pages, be less aggressive + * on reactivating pages, challenge an large set of established + * active pages with one time refaulted page may not be a good idea. + */ + if (active >= inactive_anon + inactive_file) + return distance < inactive_anon + inactive_file; + else + return distance < active + \ + (file ? inactive_anon : inactive_file); +} + #ifdef CONFIG_LRU_GEN static void *lru_gen_eviction(struct folio *folio) @@ -386,11 +460,10 @@ void *workingset_eviction(struct folio *folio, struct mem_cgroup *target_memcg) lruvec = mem_cgroup_lruvec(target_memcg, pgdat); /* XXX: target_memcg can be NULL, go through lruvec */ memcgid = mem_cgroup_id(lruvec_memcg(lruvec)); - eviction = atomic_long_read(&lruvec->nonresident_age); - eviction >>= bucket_order; + eviction = lru_eviction(lruvec, EVICTION_BITS, bucket_order); workingset_age_nonresident(lruvec, folio_nr_pages(folio)); return pack_shadow(memcgid, pgdat, eviction, - folio_test_workingset(folio)); + folio_test_workingset(folio)); } /** @@ -408,11 +481,6 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset) { struct mem_cgroup *eviction_memcg; struct lruvec *eviction_lruvec; - unsigned long refault_distance; - unsigned long inactive_file; - unsigned long inactive_anon; - unsigned long refault; - unsigned long active; int memcgid; struct pglist_data *pgdat; unsigned long eviction; @@ -421,7 +489,6 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset) return lru_gen_test_recent(shadow, file, &eviction_lruvec, &eviction, workingset); unpack_shadow(shadow, &memcgid, &pgdat, &eviction, workingset); - eviction <<= bucket_order; /* * Look up the memcg associated with the stored ID. It might @@ -442,56 +509,10 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset) eviction_memcg = mem_cgroup_from_id(memcgid); if (!mem_cgroup_disabled() && !eviction_memcg) return false; - eviction_lruvec = mem_cgroup_lruvec(eviction_memcg, pgdat); - refault = atomic_long_read(&eviction_lruvec->nonresident_age); - /* - * Calculate the refault distance - * - * The unsigned subtraction here gives an accurate distance - * across nonresident_age overflows in most cases. There is a - * special case: usually, shadow entries have a short lifetime - * and are either refaulted or reclaimed along with the inode - * before they get too old. But it is not impossible for the - * nonresident_age to lap a shadow entry in the field, which - * can then result in a false small refault distance, leading - * to a false activation should this old entry actually - * refault again. However, earlier kernels used to deactivate - * unconditionally with *every* reclaim invocation for the - * longest time, so the occasional inappropriate activation - * leading to pressure on the active list is not a problem. - */ - refault_distance = (refault - eviction) & EVICTION_MASK; - - /* - * Compare the distance to the existing workingset size. We - * don't activate pages that couldn't stay resident even if - * all the memory was available to the workingset. Whether - * workingset competition needs to consider anon or not depends - * on having free swap space. - */ - active = lruvec_page_state(eviction_lruvec, NR_ACTIVE_FILE); - inactive_file = lruvec_page_state(eviction_lruvec, NR_INACTIVE_FILE); - - if (mem_cgroup_get_nr_swap_pages(eviction_memcg) > 0) { - active += lruvec_page_state(eviction_lruvec, - NR_ACTIVE_ANON); - inactive_anon = lruvec_page_state(eviction_lruvec, - NR_INACTIVE_ANON); - } else { - inactive_anon = 0; - } - - /* - * When there are already enough active pages, be less aggressive - * on reactivating pages, challenge an large set of established - * active pages with one time refaulted page may not be a good idea. - */ - if (active >= inactive_anon + inactive_file) - return refault_distance < inactive_anon + inactive_file; - else - return refault_distance < active + (file ? inactive_anon : inactive_file); + return lru_test_refault(eviction_memcg, eviction_lruvec, eviction, + file, EVICTION_BITS, bucket_order); } /** From patchwork Wed Sep 20 19:02:41 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kairui Song X-Patchwork-Id: 13393225 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 787DFC04FEB for ; Wed, 20 Sep 2023 19:03:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DF496B0194; Wed, 20 Sep 2023 15:03:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08F836B019C; Wed, 20 Sep 2023 15:03:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E98626B019D; Wed, 20 Sep 2023 15:03:15 -0400 (EDT) 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 D8EC86B0194 for ; Wed, 20 Sep 2023 15:03:15 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B0DD9120CAC for ; Wed, 20 Sep 2023 19:03:15 +0000 (UTC) X-FDA: 81257898750.05.742BA83 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by imf14.hostedemail.com (Postfix) with ESMTP id A7B8F100034 for ; Wed, 20 Sep 2023 19:03:13 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aQlYuhu0; spf=pass (imf14.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695236593; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fTb+Ik2udqF6O5creFYnCkxLACYh4nJ1pznoCTKYdgg=; b=QcYte2tlXSaps2mpF9usf50CYaDa+isEYZR27Mekk/tmzVYIpZsg4q/p4izSZlv4HNuddB TOYLDatiwlUXuOE2RUsBKU3g9vx8LIXfJAmZO394SBoNBH4mlV66KKjycebFXZPwLcbFW4 hVEwpjXN0/2qZ0DWs/V9P2k+cEJ5omQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695236593; a=rsa-sha256; cv=none; b=At4VlyOnto9eajf4e9FxOs+5hD4moGrqOpNxrXBNkwXNCWu+WmfKyhoAnYF3+ttWu0hcDI lTz8J7PiGRZGPB42NKHbtAIzbx1BAq3mpls02ymRCAzc9gfyR4RtJtfG5Ka2TxUnk0LWwg GnichaTfAPHmuvILfNBVVAq7ynkm2es= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aQlYuhu0; spf=pass (imf14.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-68fe2470d81so111722b3a.1 for ; Wed, 20 Sep 2023 12:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695236592; x=1695841392; darn=kvack.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=fTb+Ik2udqF6O5creFYnCkxLACYh4nJ1pznoCTKYdgg=; b=aQlYuhu0kmLqDEl4U/qnuaQZmsYuNVJ8dU/xStsjbDNJUfEHh0FZoG2GeOV09gYJmQ 1j0CbxvUwoqiHY0i7oZ02jZ/vb4HmqNt5TN8RdETG7jlK7pEmOz8dwdMpk1AF2QQFilS 8QVUoDc6BfTuAY2acyez6/Dp9/TUAbCRt2XiIGq0SEBGLaA/1Plfbsi7oX20JCw+yZgc uM6j78XgmX76Mp6adeZtA+SFYL9kOyaPkHJ/ZrYYCa53rCObJF/rzUZ1qzhkyA6pWI/G 1JURs28ZJ12RK1CXwt9SC4vyz0dkE5lb7atrUSjSvU5csdqzEU5dvRea8Tzej/1D50v8 66BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695236592; x=1695841392; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fTb+Ik2udqF6O5creFYnCkxLACYh4nJ1pznoCTKYdgg=; b=kOE3jiEOa/dlydMJrNlVOVa6jMiOb4vBNbLc7zHBTpr3hkZh/MhVRvop3LzAKJk8yC qW1Cq6SWpzNdrIrDG02VowsPP4jeZbNjclpXbf8zs4lrrlWM0VnxeUYvAilj2SVnRrLw Kq9+m4UqJWdJY48C3HIuGgTj21TsJYZ/n7OgFEH0oPlY/ykeKWYLniu2VLI5omLuYuTb T5NaE1Y2ugr2zs4/6SsMbtEKdsDfPo9bAhtyNKxSu1fhN3er1chFVnywGTcHowSi1FGB /KxU7Ai1DbSBfjAN/QY9EAs4M95U89IqKJ+jSPLJv541vKaXSIkn9g80tpZZpc6FCQpL PSxQ== X-Gm-Message-State: AOJu0YwubPZq0tvux5gXYiIIbfx2Bsqo7JlnSbGdtKOpSNnKCDR9nMV2 aDd6sBta50IsyfnKWSWX4TZVeTMg1vktEWRS X-Google-Smtp-Source: AGHT+IGOR3t7SCi0X1jSkUkFA5SJ42qQ186NGsFE41qOKCO7kuJQXQAUD43UH6S65kiieutgbFyoyA== X-Received: by 2002:a05:6a20:3ca7:b0:13a:59b1:c884 with SMTP id b39-20020a056a203ca700b0013a59b1c884mr3984546pzj.40.1695236591863; Wed, 20 Sep 2023 12:03:11 -0700 (PDT) Received: from KASONG-MB2.tencent.com ([124.127.145.18]) by smtp.gmail.com with ESMTPSA id m5-20020aa78a05000000b006871fdde2c7sm423935pfa.110.2023.09.20.12.03.08 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 20 Sep 2023 12:03:11 -0700 (PDT) From: Kairui Song To: linux-mm@kvack.org Cc: Andrew Morton , Yu Zhao , Roman Gushchin , Johannes Weiner , Michal Hocko , Hugh Dickins , Nhat Pham , Yuanchu Xie , Kalesh Singh , Suren Baghdasaryan , "T . J . Mercier" , linux-kernel@vger.kernel.org, Kairui Song Subject: [RFC PATCH v3 3/6] workignset: simplify the initilization code Date: Thu, 21 Sep 2023 03:02:41 +0800 Message-ID: <20230920190244.16839-4-ryncsn@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230920190244.16839-1-ryncsn@gmail.com> References: <20230920190244.16839-1-ryncsn@gmail.com> Reply-To: Kairui Song MIME-Version: 1.0 X-Rspamd-Queue-Id: A7B8F100034 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 74aogwtzhd418b95rhue73grwzozao57 X-HE-Tag: 1695236593-710060 X-HE-Meta: U2FsdGVkX19KUsZlWfc6VxW/MhQYOnd/BOAp2IxuoIbctLm0GmlK2Vq0LNQgSamdK7CsLhNFnxxpMZueEI84VI+BsoNS0ZAbQ8IJ2bGwGaZmi8sbszy6Vn4e0J65o2PjWETuMxJpswiZqgPvtNa7q9SvZmfvLue+zqoHXBbsfXFKgASZaLU+01+yBy0gVfWIY/7+bQ0aVarzuqcRg6lsgcoD/kjkncOD1yjnkM79IHxWPxVwXekY1Ytq/WMWq1MLWzCutjg9L/c/qQmPJVTzlNkRcZ64UYeKBDKSsmGcmBZiphzZeCCPtDunhzUftvpuYzdy8MTmiv4Kr6YF9+vYqROP7qz6ZGcQK9I5Ig8DocWVAiAD5gSNWiJMY3PYy+6JCZiCha+9MYyfmxoUfaxkSEJUo06ED9L/oS7YKPrT0Eqy0+WhHa8cgINupQc7rGDH3onfiIP/e91t6QrTzwZ0UM8MkVvcTGgaHhELeeqgp7DltqC5F5XsDcGIUiV4/Uj9f6EBYfAURjvXTa4iwLuqV25pn8bQS29TMNzpVKbZWF6DYPBLlALKltzOk7uMqd/oDBFAFHZejWY9tzDPdJyFb+ymChlx4IhEjDvDX+k62kAV4yZpIFSCRd5tPJmLXA47uRI2g50d+Ad7D5qQjiTGXAnTHysrzO6aLPXPUgILhed8ulLCL5seC8gZ66Slsi/ceWAePUYBQGpEeFMn/lBWT46ROU2z0PgDAXiIz3GAOfUSYHVgaiCY3v50V4MWUvEfANKXdjfKfRr+vEPoOR/V5XWIL9SiIrF/uOzX2vBLkMeAJ7/b8o8n1ZWE5dcTJGd8aNBknW4O/us+GXqRb3/PuwmgHyDgPnIPiH2YTXJuIKQJS9Y00fWShupymcEwUH7vUvtRzum782bVQENQjJOReYcGe1jffSygG3LKBwVMpBoT/mi9h1nC5wyocQEpTfGDwlJeJRt6RXztpF4Tfom 70ZiqO0p 9P7SBF2i7qwQS4REfy8kZ0XywAAam6oXdti+BnudZGiCO6CzsZN2c5yUbpTvqPcRKEoCkRnSfQkWOp5akpojUI0AoFdqr8syCk0Wq88HPgYjVJ77L5kjIZyfbvf8lS6d5/wWyiIIBg5uKQAp/mvSWhS9JazthpTitj/M+2LV8+FcPgKki5aTPeNDa5oUozi0f00BhwA8fsgeM8RAIos2p+jVshVj/DNuXsQqwOi9kLJEq++hbaLKe3dhrLSbvebVw+gZisEm6zl07irphbu59x9oHnzBrR02L8IeSvDWHR4hy+rIjqiLrf/2Oaxnl+gQ/onBckQu0NPGogDJR5zyRZInZSzffsDpZNtfsl7t7bFUNLmccObKI96tnF4lvcUk/weJV/BmohrkZy2m8ZqvBL2Lvj/nCjMujq72jyCvxHCJGPTO+fK1qF+mQKW+VVa0M2oeBPXXfhlgwugQfIhBsDS8ROCszM0gOmRmkDy7X1pM+kW78mKxbqCaQo8O5wWk3nMAKAYw+/0XngYj3Q2W1Vf6Xl2/ctcVZ0+1kQ9hnIcz+Xi+AzMWp6IstP/o70rPi7efjq/02pDI12tp8SmIQ3taVpVmpTCHhK0W1dx/G9tmGVPITS1NCTT26nRpmJ0yhU591 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Kairui Song Use the new introduced EVICTION_BITS to replace timestamp_bits, compiler should be able to optimize out the previous variable but this should make the code more clear and unified. Signed-off-by: Kairui Song --- mm/workingset.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/mm/workingset.c b/mm/workingset.c index b0704cbfc667..278c3b9eb549 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -772,7 +772,6 @@ static struct lock_class_key shadow_nodes_key; static int __init workingset_init(void) { - unsigned int timestamp_bits; unsigned int max_order; int ret; @@ -784,12 +783,11 @@ static int __init workingset_init(void) * some more pages at runtime, so keep working with up to * double the initial memory by using totalram_pages as-is. */ - timestamp_bits = BITS_PER_LONG - EVICTION_SHIFT; max_order = fls_long(totalram_pages() - 1); - if (max_order > timestamp_bits) - bucket_order = max_order - timestamp_bits; + if (max_order > EVICTION_BITS) + bucket_order = max_order - EVICTION_BITS; pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n", - timestamp_bits, max_order, bucket_order); + EVICTION_BITS, max_order, bucket_order); ret = prealloc_shrinker(&workingset_shadow_shrinker, "mm-shadow"); if (ret) From patchwork Wed Sep 20 19:02:42 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kairui Song X-Patchwork-Id: 13393226 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 5F3C1C04FED for ; Wed, 20 Sep 2023 19:03:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4BE86B019E; Wed, 20 Sep 2023 15:03:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DFCF66B019F; Wed, 20 Sep 2023 15:03:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C751A6B01A0; Wed, 20 Sep 2023 15:03:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B3A4C6B019E for ; Wed, 20 Sep 2023 15:03:19 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 86808B3EA1 for ; Wed, 20 Sep 2023 19:03:19 +0000 (UTC) X-FDA: 81257898918.07.FE11983 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by imf17.hostedemail.com (Postfix) with ESMTP id 796D640030 for ; Wed, 20 Sep 2023 19:03:17 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=N6okLFhm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.175 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695236597; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SXDXLfwQ0rN/NkRQHGcA+48P9cgCCQ47pt4nGg6amro=; b=LSS47t4Q2VkDaqS+2eN5zSblamW1CZ12QAoXec0Sk5gJi30rB+dYKRcVQSJ/Cbl8S9OsLR DL+jJzJSSDRwXqH8fwW7aMNSCkrmJkKrsA/dhiN1fZStV9jnPQFd2IICoJ1Jfoo8s1rMXW op/Z7Pz89HcvVOJhpLIqk0HSRPaUPZY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=N6okLFhm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.175 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695236597; a=rsa-sha256; cv=none; b=G8JAB9elmOHYwSJ4IeZnHbTWFCCclodMu5zk5uHkLQCNcp4pT4aD8h7FP059SVttMybKCl w9Xkbod585iBGSSmRWfCxyUyFIF4prkxw1oX52QWtzbiJWMSXLMHk3WzTXt3XSoU5ycdmE 57jcKeruclD5zo34DtKW7opFNjZYNlo= Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-68c576d35feso105297b3a.2 for ; Wed, 20 Sep 2023 12:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695236596; x=1695841396; darn=kvack.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=SXDXLfwQ0rN/NkRQHGcA+48P9cgCCQ47pt4nGg6amro=; b=N6okLFhmeOhgtBWpAWqc8lbPkEAJEFuCe+fUn0eEqgng0ptDjxBmPQWDdPc5IBG2x9 k43zsL/dC3m5MG48N3xTyED4wkDgHezFvuOcuIHsyFz3o7LdBk5xTmWIl7xbzUu83HQG OdNtbax2bpCPcuItOCePPZ7hzLoi+zRwbU+RcFCF1ksEL6UCv4fHhCYnlkpaQEVbz/Tn 8IF2ug0jnEZ9/lP71DVhFCF+kVsRPjoy5P0nQzmucOUqbuvlpDCcP1eR3YEDfeOJZiqm OjMhhd7yuZamNq4aZBGRJSk6fjdtl+CSL6/xKWp0xhXrCX4VS3J1+iXwgN0SJrxg2uod dKLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695236596; x=1695841396; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SXDXLfwQ0rN/NkRQHGcA+48P9cgCCQ47pt4nGg6amro=; b=ka//SUFNX6zaG7Y536Rh7vF6UoWe+R3Q2TuuSFNUOaTV6leHBRlakAUFXMk5Iw7fbJ UXC7sU294DU5Ind9jn/9E/+EskCfaT2+2Z+eMAiKHnTAEf/tEeR5oguLcRotrDkR4z/l e2InYIK3ewLxi/Fe8Ym8+AbjU26Dnkw+E4uBhQQGj0YWIO+gg5mqnC2MVc00m7bfPG21 1TcIzrUQcaugyumRUGQfo92Z/eEq/DKC0Bnhnri6APB1YiwMpgagdpLuaGEaGJ/6ilQw b8PKquORL6qqgr1kq6d2yMIuIXwwASK3WlrPzMcirBkkhK2s6PWN64pbUg5JAWcH8sQ3 5uWA== X-Gm-Message-State: AOJu0YwbvOhQA4L4mzxWGpq3CY5ir16pRcYV1ahbxTbvQwSMfeO7s9NN jyNH21fTIgo4MSWjqhoGZh37bfYkENbpntqB X-Google-Smtp-Source: AGHT+IHFEuC6SGjGqdSNIHcpHwYS0ynMnc6+JDELyo8UC6MldIkjr9cwZSbjF96jMoK0A+wcrc6SDA== X-Received: by 2002:a05:6a20:1002:b0:141:d640:794a with SMTP id gs2-20020a056a20100200b00141d640794amr2885144pzc.39.1695236595707; Wed, 20 Sep 2023 12:03:15 -0700 (PDT) Received: from KASONG-MB2.tencent.com ([124.127.145.18]) by smtp.gmail.com with ESMTPSA id m5-20020aa78a05000000b006871fdde2c7sm423935pfa.110.2023.09.20.12.03.12 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 20 Sep 2023 12:03:15 -0700 (PDT) From: Kairui Song To: linux-mm@kvack.org Cc: Andrew Morton , Yu Zhao , Roman Gushchin , Johannes Weiner , Michal Hocko , Hugh Dickins , Nhat Pham , Yuanchu Xie , Kalesh Singh , Suren Baghdasaryan , "T . J . Mercier" , linux-kernel@vger.kernel.org, Kairui Song Subject: [RFC PATCH v3 4/6] workingset: simplify lru_gen_test_recent Date: Thu, 21 Sep 2023 03:02:42 +0800 Message-ID: <20230920190244.16839-5-ryncsn@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230920190244.16839-1-ryncsn@gmail.com> References: <20230920190244.16839-1-ryncsn@gmail.com> Reply-To: Kairui Song MIME-Version: 1.0 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 796D640030 X-Stat-Signature: ndjxgaibjxaitkrs1tz3d5y4zpmpbwd6 X-Rspam-User: X-HE-Tag: 1695236597-467355 X-HE-Meta: U2FsdGVkX184lLYaWuHYSRg2y65FplpMkw5UfFkZbwXsUPIYlw6hl2+hCIN8WvDLbbvfOnpyJ22dV7y0u8OtIKCCb5alThdzCX5Kv3icjsfs5TomLUK3bfscnTWgF/pHrddCYq06NuANcnnCzvB6txEY1jxFnEIHMA6ZangnuiHNUjHzOPclSJgSbOPhKIpiGe4+Hu9r69NjC/e0J0BXMEGAafy7d9ZenFMSuGa7Yeq720p3J6C6IgjGH7qdKMjNb3CkG6Agkh2lSDAiSt2cYDTPnqVO/shpGDz6kFgReWVvAshrjlTT4NM8Vbjdr9Cx5rU3YlmpPo5Xxd+mAPR5jPZBs9aMxY1MfydL5Un1UPKCIoXpM/ezCUZjXx/XSsScUoFIBczgy7x5Xpk2EqxQ3lgNYTQol8LWQYWNW2iOg/Ra8IdYbTN31XnawDBuZb0GXfrOonKgPwOXA+HTI6/iEpuXc5ks8baXLd5XTVuAZ6lSoSnJ1hPb6BP2W1Lemivz3mZ7ZimWuEp/bVkQKF1nmb0s4ACAlaC7uFl9mx/qb35GtzQgZf5OPEbkEIiA8iXamtnpzgy9acz5zutV7J170Gbm6AoCRLXxIG4p1349Gww3bnMRaa7plNmm4YIJfI4hX/42+dD6yoZsjn62nRaCno/KMwC0MWYSiO261lLhiDrZ6SfYXrPn3kdBaleB2VnKtcH29AcVvQjTEVx022Ki645tGCqZ+EG2KQqOdL3WuuVyJC7kRwyhrZfx7D/SV3/3TB3KkRl64qupOAnIrfy0JZBGVsApwvekjWv6r7cUbfk4p4G8yZcyWNhr019L9ujh/n93yLb2Ir3qcmU2f26e1h6OMsc5ikVP19Fn0nzUqDS+ynhT/i8tEvaq/A0xyX2DyVwYbng9fr44v+adQNDLf1MdBB/mqZmAL33SqgO8mEBm55Lp3ksg3qp4zmb78PXq9MIzn+jahw3URG8iveo IMmmY7/M sohvWol7PUzvE71AMmB29Jrf+lCTyIjgdZ/M75mpEBckxEe00PI0tsPAmaKUauOOzIYN5hUzCIroUHHf4Gh66XqqDVsiM17RcC+J+eyomut3xJAt/O2Pxk2eAu3dMQ1JbLk5xDfWG4kObxAC/prhYczaOdgPsUY5l5H6bYMeDrHUwSuz7guisjuYeH2OiSYAb43WegZ6ZfGyoPai0DinGDCAFimXpQeo4FgzBPXMj7xR0fOpa0yRd6M9VQzcKnjgz9Tm51Xi4mOD7Fif3I1knn6hf8RXestS9rUOgiqcKc9VdOH2YDBpkfCu5WZn6xPuFN53K34jh60INL4Hc+KdGolHzAABjBYPSPzc2MVnv41jfaV9IoVS+74rEfTgRysGy04+2AJgA8qz//hBO9BKXtRanJVbqjuGY9yg4Jt9CLVG16TKSqTWK2LHT4W0b5i2t0N9eURItOrGYK9zx8fFOBFgRupCd1BWMr3ObLk0X2vnF+H5p3nl1VQepvPVEUo35qK6Nez+aw2UTD6bx9wCxiznFFdGygGfKudNQnt3Ut716o36S7ffL0H5oIA6l0lmwytafhu5LgwQZBGjTwz2+rAreSs/xeUrkMWJ9nUkkwZAdvETtpM8xjF+FpdBcxqV5LU+UVtu9dIMFeKEBCn45vquieF2a9c2woaSxHc0oWB339b4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.019762, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Kairui Song Simplify the code, move some common path into its caller, prepare for following commits. Signed-off-by: Kairui Song --- mm/workingset.c | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/mm/workingset.c b/mm/workingset.c index 278c3b9eb549..87a16b6158e5 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -323,42 +323,38 @@ static void *lru_gen_eviction(struct folio *folio) * Tests if the shadow entry is for a folio that was recently evicted. * Fills in @lruvec, @token, @workingset with the values unpacked from shadow. */ -static bool lru_gen_test_recent(void *shadow, bool file, struct lruvec **lruvec, - unsigned long *token, bool *workingset) +static bool lru_gen_test_recent(struct lruvec *lruvec, bool file, + unsigned long token) { - int memcg_id; unsigned long min_seq; - struct mem_cgroup *memcg; - struct pglist_data *pgdat; - unpack_shadow(shadow, &memcg_id, &pgdat, token, workingset); - - memcg = mem_cgroup_from_id(memcg_id); - *lruvec = mem_cgroup_lruvec(memcg, pgdat); - - min_seq = READ_ONCE((*lruvec)->lrugen.min_seq[file]); - return (*token >> LRU_REFS_WIDTH) == (min_seq & (EVICTION_MASK >> LRU_REFS_WIDTH)); + min_seq = READ_ONCE(lruvec->lrugen.min_seq[file]); + return (token >> LRU_REFS_WIDTH) == (min_seq & (EVICTION_MASK >> LRU_REFS_WIDTH)); } static void lru_gen_refault(struct folio *folio, void *shadow) { + int memcgid; bool recent; - int hist, tier, refs; bool workingset; unsigned long token; + int hist, tier, refs; struct lruvec *lruvec; + struct pglist_data *pgdat; struct lru_gen_folio *lrugen; int type = folio_is_file_lru(folio); int delta = folio_nr_pages(folio); rcu_read_lock(); - recent = lru_gen_test_recent(shadow, type, &lruvec, &token, &workingset); + unpack_shadow(shadow, &memcgid, &pgdat, &token, &workingset); + lruvec = mem_cgroup_lruvec(mem_cgroup_from_id(memcgid), pgdat); if (lruvec != folio_lruvec(folio)) goto unlock; mod_lruvec_state(lruvec, WORKINGSET_REFAULT_BASE + type, delta); + recent = lru_gen_test_recent(lruvec, type, token); if (!recent) goto unlock; @@ -485,9 +481,6 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset) struct pglist_data *pgdat; unsigned long eviction; - if (lru_gen_enabled()) - return lru_gen_test_recent(shadow, file, &eviction_lruvec, &eviction, workingset); - unpack_shadow(shadow, &memcgid, &pgdat, &eviction, workingset); /* @@ -511,6 +504,9 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset) return false; eviction_lruvec = mem_cgroup_lruvec(eviction_memcg, pgdat); + if (lru_gen_enabled()) + return lru_gen_test_recent(eviction_lruvec, file, eviction); + return lru_test_refault(eviction_memcg, eviction_lruvec, eviction, file, EVICTION_BITS, bucket_order); } From patchwork Wed Sep 20 19:02:43 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kairui Song X-Patchwork-Id: 13393227 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 26AF7C04FEB for ; Wed, 20 Sep 2023 19:03:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA21A6B01A0; Wed, 20 Sep 2023 15:03:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A52F26B01A1; Wed, 20 Sep 2023 15:03:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A45D6B01A2; Wed, 20 Sep 2023 15:03:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 780026B01A0 for ; Wed, 20 Sep 2023 15:03:23 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 59FB71402CC for ; Wed, 20 Sep 2023 19:03:23 +0000 (UTC) X-FDA: 81257899086.09.163981F Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf28.hostedemail.com (Postfix) with ESMTP id 6240FC000A for ; Wed, 20 Sep 2023 19:03:21 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Ts80XX9/"; spf=pass (imf28.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695236601; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zmtAWomE9UHhxu4UCSwc3QxDlD+DtTBiD3PMp93+3PE=; b=HYcgGkPrRZ0RLG9mxbeRT4stVwPJNXkPNHE7+a5hoJU1/lPfOznxOz8n6Ao/ew4wRyn+Tp MtdWGRjhSpV6+5Vh4/57POQgKm+cpvfO3fWLz9Z1r0vwuepLIbrIMQRdTo+2d6OGpKwFSk rEIp5VsmhR+sAYi0gwyUJTk48i1La1g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695236601; a=rsa-sha256; cv=none; b=lNBfBV0BFqMG6X25gIF2i0sYD5/QhVu+E1KnPmkSYgHWY84NO7S/Xxzb9r0NEa6OBSPLfV DTaDtzVc08gWFw2sWbJPMpiE0Ri8LNUr7ieqSxP9PmZtmTjoRJyWhmWXRpxSXWzKM7M3eR 26n9U3ikdLqsaK61iPdU4lIP4CBSCwg= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Ts80XX9/"; spf=pass (imf28.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-68fdd6011f2so91547b3a.3 for ; Wed, 20 Sep 2023 12:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695236600; x=1695841400; darn=kvack.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=zmtAWomE9UHhxu4UCSwc3QxDlD+DtTBiD3PMp93+3PE=; b=Ts80XX9/KPQAiMk6FYwDX/0vy3XsHn87PBwrNBYZW/qtKMT4PX3A31Vh2Eta5F2hOS I5CfPKKrXRDKfuUKsxllBHtKkfmwMUPOj7Fb2nQsz3dAAqEXtbVca8OJWbQ8vfzGHNwG WAq3spQ0LgLBVm7d00MVte2ZVqKeC2j3LWUF9bpok/Rd/+dXscgWXl9424sXt3LzPbwo EmlTUXj1isfmEaws6x13xxVcv+LUdCc0nLJ+yfuwmYRVMCFkv0ieBny//db8iV+41sql 06CNE3UpI6MFjH83B8CiLvqSjPmJmZTDlpdcK66JmOa54LgK0X+5CVhThByXCbxUI4zi Aa9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695236600; x=1695841400; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zmtAWomE9UHhxu4UCSwc3QxDlD+DtTBiD3PMp93+3PE=; b=THf27LiBM9sIB5Z3m8inLD+93Hgd9CeDCP8opuwbR+jXZKQlma8bmVvKyexIqvRZzD 0yv2JKqDbArgKumjzu3ofOgAsJR1ddGTkq18ppbgb8DQaZzoWy7/045ojNSFOp0YjHdv ItF7Dn37ytsBlGkri13Ua1UsUTfvPJaCu7O9Ao6js2DcJEb3GhBinpVYGu+XUkFvhlZT XOnhhKkLovZ6xLVf6pLCNTsxhTv6Jo8PiflNR65wkKEzj7SrxuSiPjxw0PNOHOu1ABLr Ml6tAfDNsU2iEcS2FZaXi1f9leIdLK6JIUluCEBNShXDCKxrcdp7+SeUBhB6qhmXWNdH cL7A== X-Gm-Message-State: AOJu0Yw/h235ARr7DUghP4pVKAGO6HaTgzJJbOTBPBx3dBdkaZRGoJ6w FBapIKbfrMX3Af2mM244OG8r1c2tAV1SY3wJ X-Google-Smtp-Source: AGHT+IG0njOPD64WNQhILSI7Yy7mRF1jtyrvGzCcw3tGXClzEqYzeGMpn4pGWqrWE4Nnji19RDQnKw== X-Received: by 2002:a05:6a20:138c:b0:145:6857:457a with SMTP id hn12-20020a056a20138c00b001456857457amr3193200pzc.4.1695236599694; Wed, 20 Sep 2023 12:03:19 -0700 (PDT) Received: from KASONG-MB2.tencent.com ([124.127.145.18]) by smtp.gmail.com with ESMTPSA id m5-20020aa78a05000000b006871fdde2c7sm423935pfa.110.2023.09.20.12.03.15 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 20 Sep 2023 12:03:19 -0700 (PDT) From: Kairui Song To: linux-mm@kvack.org Cc: Andrew Morton , Yu Zhao , Roman Gushchin , Johannes Weiner , Michal Hocko , Hugh Dickins , Nhat Pham , Yuanchu Xie , Kalesh Singh , Suren Baghdasaryan , "T . J . Mercier" , linux-kernel@vger.kernel.org, Kairui Song Subject: [RFC PATCH v3 5/6] mm, lru_gen: convert avg_total and avg_refaulted to atomic Date: Thu, 21 Sep 2023 03:02:43 +0800 Message-ID: <20230920190244.16839-6-ryncsn@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230920190244.16839-1-ryncsn@gmail.com> References: <20230920190244.16839-1-ryncsn@gmail.com> Reply-To: Kairui Song MIME-Version: 1.0 X-Stat-Signature: wk5cjgiuzf6jr3p78h5kdi851x41xtmx X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6240FC000A X-Rspam-User: X-HE-Tag: 1695236601-147839 X-HE-Meta: U2FsdGVkX1+LTTXmM+XzAKZrtiJNLa4kmiGT9+IenpUsQJUhrp36E4C7/khm5Yt2TBEWhQitvdJQlNKAMedT7+Qn6oZp4Dr+NRr/5UGmID6PWhUw6ucnmyiYlSReQhiPC9l1yT7HPlwHZR61XhiLNR2DBjopem3MjsbFjc+9L1v1GTzRgpAdxUdP4eth8GhOHG93Bn0coc2uh1iim5vba+m627qjUuK8uFPHPNSOpMAfn1535K4svzNpVRtU3kJ649833dyZc4tLHz2JQmkBqTNsoOewOV59Z+gkynq3CscKvAn9+lGp2wB1bjsHfI1kzfLvcHLalk5qOuy5omWqPfOgS+I1VMafjW36sk1wLl0hWsxBIg3wZkUVYwCtfb3Lbg2AVyI4701w4YzpyOFoysrNr2ZIWmaqPrN45guZklie1eNpGUuxcwG4XGglPE6fUYbiFREYR7gslcFNEriJSaH1v7hppYoevDawIqcWeILGUQC/Yi4ji1MXmzEF8qtN9SxzPk0v/3k7o3kiEMnOlfWTM2pAes+VpgkWGjVjU5m8Z1b/sd0KkqNxniJXmeE4cXQff40N8KsdDMJRGSDM2TFUysyIHtxJaPW7RdYj7V0C7o8fNeUCt46jTT/K6zYW/zZwPC0PApjmNl1SpSZLsMHk5rIruRxOlDmakM1EhSwXTtW0Qmlb4QdivpQ7YGA48sSIekN5gKiJjIMLdYyhsoaKAOelBgUBGhjARk/WL+d/B6z9XhsK8FWmbfS7UfGwtmRz8wLkkfjhR7zZLeGwUqD4b6Gq3ouC+xxuE+ArRtiNGXU7a99jlM/ao6jAGnXqIeJ/WMuAiye9mlgMO4XzJhvHaVsIHxDou9kWYf7PYZIPfRJRic8s2X6oBzNeiZT2+4b87NXdaRuiw74+TPF/ZHNxdTDNGNycrQYR9BNr5oPfXLVoKG8E6zknZQPHWQvCp+dEqpDR9Y3XOYNth0b yb1DJZpC V5ceJQmHi3u8K1E/KEIBmLmFTnuO0BJq8FymRfYohefxvuRUNnJBYrKam86V6vj5f8ZKV2G8Acp/UTCNihHrDe1EdBuOvBGGmObpNtFtyUcrnSr6rhrpAW/lkJU9WTB1Gabd/h0wfy845v4nNuYvV+hv7Jr8jucBEyrQP8+VpROnFzoO4pj5JK+rboRBGfI9Wb9KGGq3MKqU2S/0W0JFolv4vop5dDdAo7ioFTyHvN5mQiHzutuKN5mGvGZDyGb5n3arj5TyvQOlxH0WSleSg/bQEqoN+bUNLciR0aipCXL91eGXRfKgRrGiAWmBCpBRcifGejJbKGCdhZBuJPmnoih513CPjzc+/uSJ4WkJtW+XZASnlwbtfT0si+RWVweQnsH/ugUtyzydY/lW9iaQ6j+pTIm7uJFXJBySI3gj6JEtNGER/oC/PWLqTUNAilta0GwGpntvD9Vl4LACQwgdm4W7R5HqluqqxUgk3hm0bvmcaR1Tgrxs8yxySCzDXzObcJqBCFQKeBtMuslpiYixQT9kJAlQf/Ru/EtoQiKDoY457U4nKH4/XxzDGgDuMo8AD2OGqmom/h4uycK9lujGs4yWxRHPJmwv5L6PQjOnfyDlA4Dg97jfh93W4Jp5iXjEjx8dqIGjb5J1/z3Tat3CmykwLeeOS4JrQrXWKAHfqybFCBYs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001575, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Kairui Song No feature change, prepare for later patch. Signed-off-by: Kairui Song --- include/linux/mmzone.h | 4 ++-- mm/vmscan.c | 16 ++++++++-------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 4106fbc5b4b3..d944987b67d3 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -425,9 +425,9 @@ struct lru_gen_folio { /* the multi-gen LRU sizes, eventually consistent */ long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES]; /* the exponential moving average of refaulted */ - unsigned long avg_refaulted[ANON_AND_FILE][MAX_NR_TIERS]; + atomic_long_t avg_refaulted[ANON_AND_FILE][MAX_NR_TIERS]; /* the exponential moving average of evicted+protected */ - unsigned long avg_total[ANON_AND_FILE][MAX_NR_TIERS]; + atomic_long_t avg_total[ANON_AND_FILE][MAX_NR_TIERS]; /* the first tier doesn't need protection, hence the minus one */ unsigned long protected[NR_HIST_GENS][ANON_AND_FILE][MAX_NR_TIERS - 1]; /* can be modified without holding the LRU lock */ diff --git a/mm/vmscan.c b/mm/vmscan.c index 3f4de75e5186..82acc1934c86 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3705,9 +3705,9 @@ static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier, int gain, struct lru_gen_folio *lrugen = &lruvec->lrugen; int hist = lru_hist_from_seq(lrugen->min_seq[type]); - pos->refaulted = lrugen->avg_refaulted[type][tier] + + pos->refaulted = atomic_long_read(&lrugen->avg_refaulted[type][tier]) + atomic_long_read(&lrugen->refaulted[hist][type][tier]); - pos->total = lrugen->avg_total[type][tier] + + pos->total = atomic_long_read(&lrugen->avg_total[type][tier]) + atomic_long_read(&lrugen->evicted[hist][type][tier]); if (tier) pos->total += lrugen->protected[hist][type][tier - 1]; @@ -3732,15 +3732,15 @@ static void reset_ctrl_pos(struct lruvec *lruvec, int type, bool carryover) if (carryover) { unsigned long sum; - sum = lrugen->avg_refaulted[type][tier] + + sum = atomic_long_read(&lrugen->avg_refaulted[type][tier]) + atomic_long_read(&lrugen->refaulted[hist][type][tier]); - WRITE_ONCE(lrugen->avg_refaulted[type][tier], sum / 2); + atomic_long_set(&lrugen->avg_refaulted[type][tier], sum / 2); - sum = lrugen->avg_total[type][tier] + + sum = atomic_long_read(&lrugen->avg_total[type][tier]) + atomic_long_read(&lrugen->evicted[hist][type][tier]); if (tier) sum += lrugen->protected[hist][type][tier - 1]; - WRITE_ONCE(lrugen->avg_total[type][tier], sum / 2); + atomic_long_set(&lrugen->avg_total[type][tier], sum / 2); } if (clear) { @@ -5885,8 +5885,8 @@ static void lru_gen_seq_show_full(struct seq_file *m, struct lruvec *lruvec, if (seq == max_seq) { s = "RT "; - n[0] = READ_ONCE(lrugen->avg_refaulted[type][tier]); - n[1] = READ_ONCE(lrugen->avg_total[type][tier]); + n[0] = atomic_long_read(&lrugen->avg_refaulted[type][tier]); + n[1] = atomic_long_read(&lrugen->avg_total[type][tier]); } else if (seq == min_seq[type] || NR_HIST_GENS > 1) { s = "rep"; n[0] = atomic_long_read(&lrugen->refaulted[hist][type][tier]); From patchwork Wed Sep 20 19:02:44 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kairui Song X-Patchwork-Id: 13393228 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 ED74AC04FEB for ; Wed, 20 Sep 2023 19:03:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8811F6B01A2; Wed, 20 Sep 2023 15:03:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 808E56B01A3; Wed, 20 Sep 2023 15:03:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65B3E6B01A4; Wed, 20 Sep 2023 15:03:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4F4046B01A2 for ; Wed, 20 Sep 2023 15:03:28 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0A643C07CB for ; Wed, 20 Sep 2023 19:03:28 +0000 (UTC) X-FDA: 81257899296.25.D34096C Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf18.hostedemail.com (Postfix) with ESMTP id B870A1C003C for ; Wed, 20 Sep 2023 19:03:25 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lBn57wa0; spf=pass (imf18.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695236605; h=from:from:sender:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Kjgv+mFujyzVEIugXeNIQdL6q9WaOAgedP9iUwn1GA0=; b=i09ekQWWhl2RkkRw/pfO4SbeQ+wmm6CCyp7JFEietbly21ilRqnn++Bd/bRCmZb8+ksas5 yNWf4hpMLPKlOHzozFVsmr2wbWlbq7nlv0F5xA01LntNa0yTkraTw2uaNtyZVXuWGUmwgE 5Nn7iyv47OsIUMuPcgBUf9cTROhEa/o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695236605; a=rsa-sha256; cv=none; b=L+kORitxRZSaxDhNaSgERv8k6ehqOzjNkH0T6FBMSjb8QEb1pVE+st5GviXxRWC75TCPjq PoaLFd30TAEhrx6TLdFPUTOVjXeny6MGU9x9ww8JZ/QU2Qvw4BbmdUjXlWAaJ3gWIfkCk2 cdN+xR8SksABCR+mJjK9wbTNsUDIWbk= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lBn57wa0; spf=pass (imf18.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-68fcb4dc8a9so107811b3a.2 for ; Wed, 20 Sep 2023 12:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695236604; x=1695841404; darn=kvack.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=Kjgv+mFujyzVEIugXeNIQdL6q9WaOAgedP9iUwn1GA0=; b=lBn57wa08sMoBbK3jvVFK3H5N6oyxZ2UjuWNwD7dO8N5bBZaiU8AOGBAHsOyASouBP oIhfoxhuKZJwNcblTUSZuJBYoL/qbdjx2bKbTjcU25/a8Q13o2Bm4qhgGqA3+7oEPpQq mV4z5ak0rU/+3pV7h6hNBw+wHE66CJhxSbRTrvTmiyyqdpusrBgbSU8ZW6YUnGfUSDXc 1vccw+QAFJDJieY0UK9oMnDNc/AR7E12N0JVhyrOvc4pQ4G/1bI+BHCXiTCKCnBa3Ju/ eYj0UZuAsQF/7RA15s1fWo3CgwgziujGHdOzob5R3HzO6Np7xYz///uqJ0Ue1D/yevJU sJKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695236604; x=1695841404; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Kjgv+mFujyzVEIugXeNIQdL6q9WaOAgedP9iUwn1GA0=; b=XcztFXrJMgB9LsTWXlAjEePRn7Ic/jYV1a8hkDh95uTdjLjCYh9YLvIrRSH3PuS44U LZIgWZIhVu1tNOl2Ppn8B5nkk+T75/Kny2TjXa/FyOJAuocr8+KqRvot+8qKaslJUnpY nxkVeObyWV4WQYzrz+iDSTjrFDQaffLiBPWt1Om5hYr4DT8vaS+SbKWQlajv1EIqWr4S eRyDAC36QjUT3ctJHEpVKIgtOM3J3J5ZnjmT4u60T4lCYv8IPCL2CdpTKaY0cZIGqZdk nSnzmo8n5k4d54jN6yHOFSV59braZrAZK60zuGM4G8vmGrhC5CMNbXhvP1kGoBmO4PME 5DaA== X-Gm-Message-State: AOJu0Yzfp7PL+b0yUMPNKsjAxBEWGAJX+snSlm7iifm4xLhnGP9aOQt4 UZlqww5935KBLt8VM5HZ7pV4+jykqXFcEVHK X-Google-Smtp-Source: AGHT+IHW6mCVr1H1UgvYhLR1rDIAuYEv8miI6LBr4eJOdwLqHAyFRjLtC/x1CL1mtMoA2avNPaZcvQ== X-Received: by 2002:a05:6a21:99a2:b0:15d:ee3:a1e3 with SMTP id ve34-20020a056a2199a200b0015d0ee3a1e3mr1350694pzb.16.1695236603799; Wed, 20 Sep 2023 12:03:23 -0700 (PDT) Received: from KASONG-MB2.tencent.com ([124.127.145.18]) by smtp.gmail.com with ESMTPSA id m5-20020aa78a05000000b006871fdde2c7sm423935pfa.110.2023.09.20.12.03.20 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 20 Sep 2023 12:03:23 -0700 (PDT) From: Kairui Song To: linux-mm@kvack.org Cc: Andrew Morton , Yu Zhao , Roman Gushchin , Johannes Weiner , Michal Hocko , Hugh Dickins , Nhat Pham , Yuanchu Xie , Kalesh Singh , Suren Baghdasaryan , "T . J . Mercier" , linux-kernel@vger.kernel.org, Kairui Song Subject: [RFC PATCH v3 6/6] workingset, lru_gen: apply refault-distance based re-activation Date: Thu, 21 Sep 2023 03:02:44 +0800 Message-ID: <20230920190244.16839-7-ryncsn@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230920190244.16839-1-ryncsn@gmail.com> References: <20230920190244.16839-1-ryncsn@gmail.com> Reply-To: Kairui Song MIME-Version: 1.0 X-Rspamd-Queue-Id: B870A1C003C X-Rspam-User: X-Stat-Signature: pdinrbdtwtg3n3nsuq66m3ksajkzw5s4 X-Rspamd-Server: rspam03 X-HE-Tag: 1695236605-500510 X-HE-Meta: U2FsdGVkX1+Qzrkr8BWEWJu+8aJfzgQ+Pxn9OSLBUaFeq6MWKdvcLKg3c1t5jIodDND3euS5ndL5ZJDKal63gII+rzeq9J7fafAyL99sBFDiQ0w742Ne5JoQ5hf58Zrf7WXCPfhEHwPeUrRBWQi90bgLzFJLoJ6XPWjrr+8JR33BaP1XH/2LwlvxeDB6V3LhmFwOchbgmQdyA1z6ci8jDhY98zegz6ZdRbhTT6FqXHz8Qv+4Cx9lIsjKLXZ0b4IW/ErY9amQMbZHSLLhMtBh0mEnl/GFh81v7AQN+zDNRtriKDI3sOM+UkAxmF4q6cScxNHf30POTsRmGJhOjkfsEmini5UhakQPdt0hGVGzSwRZawyKgwyznowP8s4qAtobQveEBJyyz0W6+mrpNlE3IuO9SJwufiktaklvGBoLpcP3/UC9Jji4a3162eEJYdLzCclSe88xQEC9zpyQhQ57anrgC+XSg5GqKcOiHbb87MwaFuEmrbgXBnuIBqaCW/9vD3P8YkPU/zqyf0AASirTu+xGNoXh3cl+nbXEGRo4b4pEDJ1OSsMT2LuPgddU2PY1h4hK9Kv/aCi/f3qLqsew9lBhjPbhQYgG5X7Wq6oaeqDEV39fRIA516aEMrxg9l5sDZnmKpPREIFqXtMob0kD0z2M2WXniHG/iEYPlxbFd5mdjUB4gVANau6Qg5HDh9TNfvC+eRKW591TXJZm4xXXw4Ixnrg2LpeeuSAPplcBmB+7+y8QBRfkKud/a2tTo7juSkfpksrrnWrVqGb/MVQEn+3lyDgX+jrIoJYp+5YTnAG7S/FPRj8Bou4P6DSAYmEJUvRNVNCEKAIw0s8+wGnHVKCnZCQxjm8hlG5TW+eYQr9arCq8Fv3BWy9g93dB+/2EQ8zSDNASrj82GvDTh7AcxIr4NyU1+xZXPT2DaAesnEPQP13orl1vEWUyAvFThmEz+Cklpl4UowrvI7uQWU2 MquarRgb oU/RcdNHQpGQLDmXJ4BKGFRnXwYDMxW1RJE2B9mGHGBrUtkh0d+HuE0b0Svq4jqsuAjoaKoh2XGmXJsNf+4AELkQgEwYRrbCLzioOzL0ZJlP8OdTBLX4TKd3BT8Bestn/bCKzq9tF5+qgYFHgYJV6CkwVwQwpaPbD5z1iDhOSTXXzjMQOjMX7QT7s3V6lHduJLfB9VCiAgdYYve9asB9efE98RO4olPY/5J4c6T6H1uAhMT0NznK5UaTwJVsFencPlUvVxq4jaFmmABijHzxVKQIzQlaTWW5Ye+igIpCPr8QMwM+bh6ZoO0H5e7fr3K16XTn1foq1xiuyDc+REH2N76ZC9SejopAEIQPcS5dbg45sN/Zrt0JTTROaIAtJTbFegZFCnPWRtDztBmFbEBisNRtqXU+/fvviNwu5aPmwqMVYXFJaT4//H6woi1aPsGbVXjascNfnmkh1dXawxTDPbt0KIpnjBZKfPfvwx+0D1cUqxcdB5+kRqZtqglQ5+BftWCRUZ5mSDfjwiRyyEAlX3o3foXjCGS/i9x0AFcGrQaTskLDFIja+zKjHRas8ezX6mqog2vmjcQxDyfVF04GqU6PhXZFge5UsAfpONUYGGlDs6dPziSvnQ7mTK8HzD5Zocn+nBFvG5d6wFY4Hgen7C/yQjIoAm7F78FFej4XnnLgPceT6Ik9b19wJW56JQbynA2LyGWyA80DDLBI= 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: From: Kairui Song I noticed MGLRU not working very well on certain workflows, which is observed on some heavily stressed databases. That is when the file page workingset size exceeds total memory, and the access distance (the left-shift time of a page before it gets activated, considering LRU starts from right) of file pages also larger than total memory. All file pages are stuck on the oldest generation and getting read-in then evicted permutably. Despite anon pages being idle, they never get aged. PID controller didn't kickin until there are some minor access pattern changes. And file pages are not promoted or reused. Even though the memory can't cover the whole workingset, the refault-distance based re-activation can help hold part of the workingset in-memory to help reduce the IO workload significantly. So apply it for MGLRU as well. The updated refault-distance model fits well for MGLRU in most cases, if we just consider the last two generation as the inactive LRU and the first two generations as active LRU. Some adjustment is done to fit the logic better, also make the refault-distance contributed to page tiering and PID refault detection of MGLRU: - If a tier-0 page have a qualified refault-distance, just promote it to higher tier, send it to second oldest gen. - If a tier >= 1 page have a qualified refault-distance, mark it as active and send it to youngest gen. - Increase the reference of every page that have a qualified refault-distance and increase the PID countroled refault rate of the updated tier, in hope similar paged will be protected next time upon eviction. NOTE: This also changed the meaning of workingset_* fields in /proc/vmstat, workingset_activate_* now stands for the pages reactivated or promoted by refault distance checking, workingset_restore_* now stands for all pages promoted by any reason. Following benchmark showed 5x improvement. To simulate the optimized workflow, I setup a 3-replicated mongodb cluster, each in a different cgroup, using 5 gb of wiretiger cache and 10g of oplog, on a 32G VM with no limit set. The benchmark is done using https://github.com/apavlo/py-tpcc.git, modified to run STOCK_LEVEL query only, for simulating slow query and get a stable result. Test is done on an EPYC 7K62 with 32G RAM with SATA SSD: - Before (with ZRAM enabled, the result won't change whether any kind of swap is on or not): $ tpcc.py --config=mongodb.config mongodb --duration=900 --warehouses=500 --clients=30 ================================================================== Execution Results after 919 seconds ------------------------------------------------------------------ Executed Time (µs) Rate STOCK_LEVEL 577 27584645283.7 0.02 txn/s ------------------------------------------------------------------ TOTAL 577 27584645283.7 0.02 txn/s $ cat /proc/vmstat | grep workingset workingset_nodes 47860 workingset_refault_anon 0 workingset_refault_file 23498953 workingset_activate_anon 0 workingset_activate_file 23487840 workingset_restore_anon 0 workingset_restore_file 18553646 workingset_nodereclaim 768 $ free -m total used free shared buff/cache available Mem: 31849 6829 790 23 24229 24542 Swap: 31848 0 31848 - Patched: (with ZRAM enabled): $ tpcc.py --config=mongodb.config mongodb --duration=900 --warehouses=500 --clients=30 ================================================================== Execution Results after 905 seconds ------------------------------------------------------------------ Executed Time (µs) Rate STOCK_LEVEL 2542 27121571486.2 0.09 txn/s ------------------------------------------------------------------ TOTAL 2542 27121571486.2 0.09 txn/s $ cat /proc/vmstat | grep working workingset_nodes 70358 workingset_refault_anon 16853 workingset_refault_file 22693601 workingset_activate_anon 10099 workingset_activate_file 8565519 workingset_restore_anon 10127 workingset_restore_file 8566053 workingset_nodereclaim 9801 $ free -m total used free shared buff/cache available Mem: 31849 7093 283 4 24472 24289 Swap: 31848 1652 30196 The performance is 5x times better than before, and the idle anon pages now can get swapped out as expected. The result is also better with lower test stress, testing with lower stress also shows a improvement. I also checked the benchmark with memtier/memcached and fio, using similar setup as in commit ac35a4902374 but scaled down to fit in my test environment: memtier test (16G ramdisk as swap, 4G memcg limit, VM on a EPYC 7K62): memcached -u nobody -m 16384 -s /tmp/memcached.socket -a 0766 \ -t 16 -B binary & memtier_benchmark -S /tmp/memcached.socket -P memcache_binary -n allkeys\ --key-minimum=1 --key-maximum=36000000 --key-pattern=P:P -c 1 \ -t 16 --ratio 1:0 --pipeline 8 -d 600 -x 6 fio test 1 (16G ramdisk, 4G memcg limit, VM on a EPYC 7K62): fio -name=mglru --numjobs=16 --directory=/mnt --size=1000m \ --buffered=1 --ioengine=io_uring --iodepth=128 \ --iodepth_batch_submit=32 --iodepth_batch_complete=32 \ --rw=randread --random_distribution=zipf:1.2 --norandommap \ --time_based --ramp_time=10m --runtime=5m --group_reporting fio test 2 (16G ramdisk, 2G memcg limit, VM on a EPYC 7K62): fio -name=mglru --numjobs=16 --directory=/mnt --size=1000m \ --buffered=1 --ioengine=io_uring --iodepth=128 \ --iodepth_batch_submit=32 --iodepth_batch_complete=32 \ --rw=randread --random_distribution=zipf:1.2 --norandommap \ --time_based --ramp_time=10m --runtime=5m --group_reporting mysql test (15G buffer pool with 16G memcg limit, VM on a EPYC 7K62): sysbench /usr/share/sysbench/oltp_read_only.lua \ --tables=48 --table-size=2000000 --threads=16 --time=1800 run Before this patch: memtier: 37794.71 op/s fio 1: 6327.3k iops fio 2: 5697.6k iops mysql: 146104.98 qps After this patch: memtier: 37792.61 op/s fio 1: 6583.3k iops fio 2: 5929.2k iops mysql: 146055.88 qps There is no regression on other tests so far, and a performance gain is observed on file page heavy tasks. Signed-off-by: Kairui Song --- mm/vmscan.c | 20 +++++--- mm/workingset.c | 130 +++++++++++++++++++++++++++++++----------------- 2 files changed, 95 insertions(+), 55 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 82acc1934c86..c7745b22cc0b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3730,17 +3730,21 @@ static void reset_ctrl_pos(struct lruvec *lruvec, int type, bool carryover) for (tier = 0; tier < MAX_NR_TIERS; tier++) { if (carryover) { - unsigned long sum; + unsigned long refaulted, total; - sum = atomic_long_read(&lrugen->avg_refaulted[type][tier]) + - atomic_long_read(&lrugen->refaulted[hist][type][tier]); - atomic_long_set(&lrugen->avg_refaulted[type][tier], sum / 2); + refaulted = atomic_long_read(&lrugen->avg_refaulted[type][tier]) + + atomic_long_read(&lrugen->refaulted[hist][type][tier]); - sum = atomic_long_read(&lrugen->avg_total[type][tier]) + - atomic_long_read(&lrugen->evicted[hist][type][tier]); + total = atomic_long_read(&lrugen->avg_total[type][tier]) + + atomic_long_read(&lrugen->evicted[hist][type][tier]); if (tier) - sum += lrugen->protected[hist][type][tier - 1]; - atomic_long_set(&lrugen->avg_total[type][tier], sum / 2); + total += lrugen->protected[hist][type][tier - 1]; + + /* total could be less than refaulted, see lru_gen_refault */ + total = max(total, refaulted); + + atomic_long_set(&lrugen->avg_refaulted[type][tier], refaulted / 2); + atomic_long_set(&lrugen->avg_total[type][tier], total / 2); } if (clear) { diff --git a/mm/workingset.c b/mm/workingset.c index 87a16b6158e5..e548c8cee9ad 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -175,6 +175,7 @@ MEM_CGROUP_ID_SHIFT) #define EVICTION_BITS (BITS_PER_LONG - (EVICTION_SHIFT)) #define EVICTION_MASK (~0UL >> EVICTION_SHIFT) +#define LRU_GEN_EVICTION_BITS (EVICTION_BITS - LRU_REFS_WIDTH - LRU_GEN_WIDTH) /* * Eviction timestamps need to be able to cover the full range of @@ -185,6 +186,7 @@ * evictions into coarser buckets by shaving off lower timestamp bits. */ static unsigned int bucket_order __read_mostly; +static unsigned int lru_gen_bucket_order __read_mostly; static void *pack_shadow(int memcgid, pg_data_t *pgdat, unsigned long eviction, bool workingset) @@ -290,6 +292,34 @@ static inline bool lru_test_refault(struct mem_cgroup *memcg, (file ? inactive_anon : inactive_file); } +/** + * workingset_age_nonresident - age non-resident entries as LRU ages + * @lruvec: the lruvec that was aged + * @nr_pages: the number of pages to count + * + * As in-memory pages are aged, non-resident pages need to be aged as + * well, in order for the refault distances later on to be comparable + * to the in-memory dimensions. This function allows reclaim and LRU + * operations to drive the non-resident aging along in parallel. + */ +void workingset_age_nonresident(struct lruvec *lruvec, unsigned long nr_pages) +{ + /* + * Reclaiming a cgroup means reclaiming all its children in a + * round-robin fashion. That means that each cgroup has an LRU + * order that is composed of the LRU orders of its child + * cgroups; and every page has an LRU position not just in the + * cgroup that owns it, but in all of that group's ancestors. + * + * So when the physical inactive list of a leaf cgroup ages, + * the virtual inactive lists of all its parents, including + * the root cgroup's, age as well. + */ + do { + atomic_long_add(nr_pages, &lruvec->nonresident_age); + } while ((lruvec = parent_lruvec(lruvec))); +} + #ifdef CONFIG_LRU_GEN static void *lru_gen_eviction(struct folio *folio) @@ -311,10 +341,14 @@ static void *lru_gen_eviction(struct folio *folio) lruvec = mem_cgroup_lruvec(memcg, pgdat); lrugen = &lruvec->lrugen; min_seq = READ_ONCE(lrugen->min_seq[type]); + token = (min_seq << LRU_REFS_WIDTH) | max(refs - 1, 0); + token <<= LRU_GEN_EVICTION_BITS; + token |= lru_eviction(lruvec, LRU_GEN_EVICTION_BITS, lru_gen_bucket_order); hist = lru_hist_from_seq(min_seq); atomic_long_add(delta, &lrugen->evicted[hist][type][tier]); + workingset_age_nonresident(lruvec, folio_nr_pages(folio)); return pack_shadow(mem_cgroup_id(memcg), pgdat, token, refs); } @@ -329,15 +363,17 @@ static bool lru_gen_test_recent(struct lruvec *lruvec, bool file, unsigned long min_seq; min_seq = READ_ONCE(lruvec->lrugen.min_seq[file]); + token >>= LRU_GEN_EVICTION_BITS; return (token >> LRU_REFS_WIDTH) == (min_seq & (EVICTION_MASK >> LRU_REFS_WIDTH)); } static void lru_gen_refault(struct folio *folio, void *shadow) { int memcgid; - bool recent; + bool refault; bool workingset; unsigned long token; + bool recent = false; int hist, tier, refs; struct lruvec *lruvec; struct pglist_data *pgdat; @@ -345,28 +381,36 @@ static void lru_gen_refault(struct folio *folio, void *shadow) int type = folio_is_file_lru(folio); int delta = folio_nr_pages(folio); - rcu_read_lock(); - unpack_shadow(shadow, &memcgid, &pgdat, &token, &workingset); lruvec = mem_cgroup_lruvec(mem_cgroup_from_id(memcgid), pgdat); if (lruvec != folio_lruvec(folio)) - goto unlock; + return; mod_lruvec_state(lruvec, WORKINGSET_REFAULT_BASE + type, delta); - + refault = lru_test_refault(lruvec_memcg(lruvec), lruvec, token, type, + LRU_GEN_EVICTION_BITS, lru_gen_bucket_order); recent = lru_gen_test_recent(lruvec, type, token); - if (!recent) - goto unlock; + if (!recent && !refault) + return; lrugen = &lruvec->lrugen; - hist = lru_hist_from_seq(READ_ONCE(lrugen->min_seq[type])); /* see the comment in folio_lru_refs() */ + token >>= LRU_GEN_EVICTION_BITS; refs = (token & (BIT(LRU_REFS_WIDTH) - 1)) + workingset; tier = lru_tier_from_refs(refs); - atomic_long_add(delta, &lrugen->refaulted[hist][type][tier]); - mod_lruvec_state(lruvec, WORKINGSET_ACTIVATE_BASE + type, delta); + if (refault) { + if (refs) + folio_set_active(folio); + /* + * Protect higher tier to make it easier + * to stay in a stable workingset and prevent refault. + */ + if (refs != BIT(LRU_REFS_WIDTH)) + tier = lru_tier_from_refs(refs + 1); + mod_lruvec_state(lruvec, WORKINGSET_ACTIVATE_BASE + type, delta); + } /* * Count the following two cases as stalls: @@ -375,12 +419,25 @@ static void lru_gen_refault(struct folio *folio, void *shadow) * 2. For pages accessed multiple times through file descriptors, * numbers of accesses might have been out of the range. */ - if (lru_gen_in_fault() || refs == BIT(LRU_REFS_WIDTH)) { - folio_set_workingset(folio); + if (refault || lru_gen_in_fault() || refs == BIT(LRU_REFS_WIDTH)) { mod_lruvec_state(lruvec, WORKINGSET_RESTORE_BASE + type, delta); + folio_set_workingset(folio); + } + + /* + * If recent is false, add to global PID counters since the gen which + * the page evicted is gone already. + */ + if (recent) { + /* + * tier may get increased upon refault, which makes refaulted larger + * than evicted, this will be reset and accounted by reset_ctrl_pos + */ + atomic_long_add(delta, &lrugen->refaulted[hist][type][tier]); + } else { + atomic_long_add(delta, &lrugen->avg_total[type][tier]); + atomic_long_add(delta, &lrugen->avg_refaulted[type][tier]); } -unlock: - rcu_read_unlock(); } #else /* !CONFIG_LRU_GEN */ @@ -402,34 +459,6 @@ static void lru_gen_refault(struct folio *folio, void *shadow) #endif /* CONFIG_LRU_GEN */ -/** - * workingset_age_nonresident - age non-resident entries as LRU ages - * @lruvec: the lruvec that was aged - * @nr_pages: the number of pages to count - * - * As in-memory pages are aged, non-resident pages need to be aged as - * well, in order for the refault distances later on to be comparable - * to the in-memory dimensions. This function allows reclaim and LRU - * operations to drive the non-resident aging along in parallel. - */ -void workingset_age_nonresident(struct lruvec *lruvec, unsigned long nr_pages) -{ - /* - * Reclaiming a cgroup means reclaiming all its children in a - * round-robin fashion. That means that each cgroup has an LRU - * order that is composed of the LRU orders of its child - * cgroups; and every page has an LRU position not just in the - * cgroup that owns it, but in all of that group's ancestors. - * - * So when the physical inactive list of a leaf cgroup ages, - * the virtual inactive lists of all its parents, including - * the root cgroup's, age as well. - */ - do { - atomic_long_add(nr_pages, &lruvec->nonresident_age); - } while ((lruvec = parent_lruvec(lruvec))); -} - /** * workingset_eviction - note the eviction of a folio from memory * @target_memcg: the cgroup that is causing the reclaim @@ -529,16 +558,16 @@ void workingset_refault(struct folio *folio, void *shadow) bool workingset; long nr; - if (lru_gen_enabled()) { - lru_gen_refault(folio, shadow); - return; - } - /* Flush stats (and potentially sleep) before holding RCU read lock */ mem_cgroup_flush_stats_ratelimited(); rcu_read_lock(); + if (lru_gen_enabled()) { + lru_gen_refault(folio, shadow); + goto out; + } + /* * The activation decision for this folio is made at the level * where the eviction occurred, as that is where the LRU order @@ -785,6 +814,13 @@ static int __init workingset_init(void) pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n", EVICTION_BITS, max_order, bucket_order); +#ifdef CONFIG_LRU_GEN + if (max_order > LRU_GEN_EVICTION_BITS) + lru_gen_bucket_order = max_order - LRU_GEN_EVICTION_BITS; + pr_info("workingset: lru_gen_timestamp_bits=%d lru_gen_bucket_order=%u\n", + LRU_GEN_EVICTION_BITS, lru_gen_bucket_order); +#endif + ret = prealloc_shrinker(&workingset_shadow_shrinker, "mm-shadow"); if (ret) goto err;