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 43A28EB64DA for ; Thu, 20 Jul 2023 16:24:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A696A28012B; Thu, 20 Jul 2023 12:24:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A19D428004C; Thu, 20 Jul 2023 12:24:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8BA8728012B; Thu, 20 Jul 2023 12:24:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 785AF28004C for ; Thu, 20 Jul 2023 12:24:45 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2E2C21401AC for ; Thu, 20 Jul 2023 16:24:45 +0000 (UTC) X-FDA: 81032513730.15.AF9785A Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf03.hostedemail.com (Postfix) with ESMTP id CDA0D2001C for ; Thu, 20 Jul 2023 16:24:42 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=IZzpQokK; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.176 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689870283; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=s74T/DS0uEk+n6R0wwBy5aetjEjuSLERJS55RIwoaX4=; b=C/hyli8s0axn2zYhflWI5VLwy1CLQu4CzvXrZd5hPKX3Qo+JckAGv7Sv/MSCZ62cPbsvXD E6phR9Qqb30vrARgXNcqBWfaq8F4UzDS6tuyjatyhvTrIqdhCZTN5dXCHlpeNGFtFFRdoX KqJEI26FRWSwYwsoC/jaTmWeUampGwE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689870283; a=rsa-sha256; cv=none; b=wSf9XBauGdNS6OWE/AcUdB5rdXr0HnywfFWGXaTQnKh2G9jHNOnMvgW65KZ6PeOPLXdCdD eQt162YHigAmN/lY8iZScMs0CCmPtMjvL2a9ezndMQno0i9Tao52ej/0+wW+p8F283aH+X HWcWb5lLkGgMutnkZEqFuzLeinJTIPw= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=IZzpQokK; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.176 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-401e23045beso9065751cf.0 for ; Thu, 20 Jul 2023 09:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20221208.gappssmtp.com; s=20221208; t=1689870282; x=1690475082; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=s74T/DS0uEk+n6R0wwBy5aetjEjuSLERJS55RIwoaX4=; b=IZzpQokKpB0UhARjk1C5AYsxhEoUwekbG1CIGPqpzF+J5EyUNV4fXvSh6ICM60s/l/ l3LTb+/4oHtXOm/axHhrDe9RYyjLFUcJp/fjdEfH3AfdarB9wYiD6qDHqXQIUGTULJjY vw7yjUAGA6a1rzcc8PN64w16jP4JWgFnyix3oUPgbdJpcchORfcHKjhuGO7hDatwjMex Tgoo3H3N3xNYsZnI1oMU+JFxWEkqso9+qil3xyi6Lze7Drl2ReIPDqQjSEa8jAMYviY/ z9eO+nZw1PsJ45lS/RFq6qSgkSD6Jl0gP4PD3UUJ8jAvUFV4u798afEKcJEM6QS2Vj9Y 5HwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689870282; x=1690475082; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s74T/DS0uEk+n6R0wwBy5aetjEjuSLERJS55RIwoaX4=; b=L4CacvWI08p5TjPL020oWeLhMxCU7Hb1PN2YBsncYYozkqj07fsLSVSwSR1XsdGp41 vS4kmywCdUVK/ETvUFoI64koDexNeScZNYt66nUdACodeh8jex64wyVjtMPfYpp4nFRP f012sygmarqeljdDtH8xtUpZy716Qa6PQcumcBEpmb6Y7Ok8Fi5bhG5+87NdymvVnPQF ZlnBuiEaVNomYbtxTL38uPk6NxV5cyaRknqNkMfwLSzjZLDV8s+jmXYACSH93+6RE2Dv /u4lJXrEDaQphjU5Lnu85Oy7d/EFSiXp6OPuCrL2rvQtuz3ADuItDrFgOFpjFafFAmrV hiJg== X-Gm-Message-State: ABy/qLaUq/jfznbWkdjsdrvEu1S5KVQolJbDHhq3wSIfbJDpj1QIVZ5c XTk+4Km2/wGUSjK+GkJQZfECxw== X-Google-Smtp-Source: APBJJlFgEYqldxkiOjJHk0bAl/tukxpRZVH2RVuIZHt9j9/eVwHSR5HC6Q+XrizCrjEJ9XxT5shHCA== X-Received: by 2002:ac8:598d:0:b0:403:b4da:6e53 with SMTP id e13-20020ac8598d000000b00403b4da6e53mr3014943qte.44.1689870281860; Thu, 20 Jul 2023 09:24:41 -0700 (PDT) Received: from localhost (2603-7000-0c01-2716-8f57-5681-ccd3-4a2e.res6.spectrum.com. [2603:7000:c01:2716:8f57:5681:ccd3:4a2e]) by smtp.gmail.com with ESMTPSA id s41-20020a05622a1aa900b00405447ee5e8sm457395qtc.55.2023.07.20.09.24.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 09:24:41 -0700 (PDT) Date: Thu, 20 Jul 2023 12:24:40 -0400 From: Johannes Weiner To: Efly Young Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, Michal Hocko , Shakeel Butt , Yosry Ahmed Subject: Re: [PATCH] mm:vmscan: fix inaccurate reclaim during proactive reclaim Message-ID: <20230720162440.GA1015794@cmpxchg.org> References: <20230720072708.55067-1-yangyifei03@kuaishou.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230720072708.55067-1-yangyifei03@kuaishou.com> X-Rspamd-Queue-Id: CDA0D2001C X-Rspam-User: X-Stat-Signature: 71zoa796sftzn39ir841ccfyysj8495i X-Rspamd-Server: rspam03 X-HE-Tag: 1689870282-73878 X-HE-Meta: U2FsdGVkX18XDMtTvqRHiRpzS5P6l5/gbFjMUH7lA+hBqN9JzPpfK1LwQCIFsSIN9wZkdQQp6Uy3U2G0K3ndUsN3OfsToyRXiY+WR9YHSyrJ57y/GWSVl+AAw7lw63+8MFmN+QpBZahc8ZK3AObryerx6qmgoToaI2BwHmo+teAKSkmgGWJPPqgH9dWUvTnq2wsaK20vX1/xL1LKJRKTWpN+lYNEf0kb6LhfqVFDxhkyhV+Un2KkDYLzm6wwPdXgW8IVjQTCFXhnfZYxQtlFblsR7aoLucjXtWDWp2zmQvN9lLlXBPNXBa4LJ9H2dCqYXVR2MG8zRxqmxM8T132ktwHav9DEj07QcW0hQqe3Atyd/i2X+JjyPtEpCUwyPJ4c1wCkqG+/QE2lePZacg4BScc+KGbvczsU7LTvCxHlz3ZUpj0EsIxiiej3DHfIEIBXL2fJFTkv+ktKK0/ll8LRVLyADydQHl82Ma8rDhN626ab9Wd4LQQmo2kK8QQVZHBb8kcw+Fm7OrhhYg0HSmSj1rl6OBxJ6fZHjaM+hqbiKql/GIb5zSOPSsJa1C6UuY4QL4+0LDnZkB9T+thyLXRh/+5s9kc/ukragZsfOG1pn+9oGetBI5mX9ibPRcHDY43EC8EJ0ghL05Vv7IGnOv7cDUGdu6DPoIz4Zp5uaIWq6RFlr+fe6Kmd2Jz8PreBYWyX3b62CHHUrMrMpIVrhGg8eDpK2rcksP9dG0lUJTb5eEGyA+Pp1y7m2ZaEvNXWiebfg0Gq/bqJB0GdZd8BQz3QP1BlTnFchI6YVTLm3g4OtJIHfF2rutbmBVR1NCUPQhviMKZO60Z5yeVirxROcl4954l0YROwQWwDgTG0H1kNvpok3z3M2QpSN5KKUYfqtrrZNytPcBd12hCl36XDyq09hdzMJLqBtixJOIQSOALPJdth8j/40HuwV656/hey5uu3877bo+WS5WwOXFNzjjH LKxYFQMi NpHma/AkmqtiZT9xaOHjNVXBJiIgUrl31wIhkIzvdFSKG2kkwChLSgr4nip6uwvUQQ7bz89ntGAE07e0bM+CYO4XaHM/o0afQoDaHA8LbVwcy/o5vCFaLl8q57/KBtSjLJhoXHo5Ua8shvcths6RwzXmE2ztTlBzoVQ11meafQzceUi3drcWbcDFJ4I+k4J7GRqgsWSvnCNGWBLrpH6NoKtZ26NeRFJhdfbZmwvuenlhvxJocAtGgMqruTjYHtOxHioe1pTkGWqQHE4x2RRTVzN63Bo0PtkmI/9m5v91sHLTGeiUh7239DdofatXHCaxcVU3NBsoR8XciSaZ2svuPSURTDgJFd53B3LNcsYfqRjiPGsCYhY9h+ltFLnyrA/rHcA+x7ZUSHPLfEDuVmecwfuG0g9nKx5RnehQRVY4Y/1PvFaRa3T39MY+bXJAvQ+OnK2X+Ti+sf4WuNjcTBufTgoaMqxtyIiGOIHxpavVmxsRNql5bMnu3Z8UcYeEge22wLIzzoZ6V4iSMxy0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 20, 2023 at 03:27:08PM +0800, Efly Young wrote: > Before commit f53af4285d77 ("mm: vmscan: fix extreme overreclaim and > swap floods"), proactive reclaim will extreme overreclaim sometimes. > But proactive reclaim still inaccurate and some extent overreclaim. > > Problematic case is easy to construct. Allocate lots of anonymous > memory (e.g., 20G) in a memcg, then swapping by writing memory.recalim > and there is a certain probability of overreclaim. For example, request > 1G by writing memory.reclaim will eventually reclaim 1.7G or other > values more than 1G. > > The reason is that reclaimer may have already reclaimed part of requested > memory in one loop, but before adjust sc->nr_to_reclaim in outer loop, > call shrink_lruvec() again will still follow the current sc->nr_to_reclaim > to work. It will eventually lead to overreclaim. In theory, the amount > of reclaimed would be in [request, 2 * request). > > Reclaimer usually tends to reclaim more than request. But either direct > or kswapd reclaim have much smaller nr_to_reclaim targets, so it is > less noticeable and not have much impact. > > Proactive reclaim can usually come in with a larger value, so the error > is difficult to ignore. Considering proactive reclaim is usually low > frequency, handle the batching into smaller chunks is a better approach. > > Signed-off-by: Efly Young > Signed-off-by: Johannes Weiner Hey, I didn't write the patch, you did :) Please change it to Suggested-by: Johannes Weiner You can also add Acked-by: Johannes Weiner [quoting remainder for new CCs] > --- > mm/memcontrol.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 4b27e24..d36cf88 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -6741,8 +6741,8 @@ static ssize_t memory_reclaim(struct kernfs_open_file *of, char *buf, > lru_add_drain_all(); > > reclaimed = try_to_free_mem_cgroup_pages(memcg, > - nr_to_reclaim - nr_reclaimed, > - GFP_KERNEL, reclaim_options); > + min(nr_to_reclaim - nr_reclaimed, SWAP_CLUSTER_MAX), > + GFP_KERNEL, reclaim_options); > > if (!reclaimed && !nr_retries--) > return -EAGAIN; > -- > 1.8.3.1