All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: "T.J. Mercier" <tjmercier@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Shakeel Butt <shakeelb@google.com>,
	Muchun Song <muchun.song@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	android-mm@google.com, yuzhao@google.com,
	yangyifei03@kuaishou.com, cgroups@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "mm:vmscan: fix inaccurate reclaim during proactive reclaim"
Date: Tue, 23 Jan 2024 10:33:36 +0100	[thread overview]
Message-ID: <Za-H8NNW9bL-I4gj@tiehlicka> (raw)
In-Reply-To: <20240121214413.833776-1-tjmercier@google.com>

On Sun 21-01-24 21:44:12, T.J. Mercier wrote:
> This reverts commit 0388536ac29104a478c79b3869541524caec28eb.
> 
> Proactive reclaim on the root cgroup is 10x slower after this patch when
> MGLRU is enabled, and completion times for proactive reclaim on much
> smaller non-root cgroups take ~30% longer (with or without MGLRU).

What is the reclaim target in these pro-active reclaim requests?

> With
> root reclaim before the patch, I observe average reclaim rates of
> ~70k pages/sec before try_to_free_mem_cgroup_pages starts to fail and
> the nr_retries counter starts to decrement, eventually ending the
> proactive reclaim attempt.

Do I understand correctly that the reclaim target is over estimated and
you expect that the reclaim process breaks out early>

> After the patch the reclaim rate is
> consistently ~6.6k pages/sec due to the reduced nr_pages value causing
> scan aborts as soon as SWAP_CLUSTER_MAX pages are reclaimed. The
> proactive reclaim doesn't complete after several minutes because
> try_to_free_mem_cgroup_pages is still capable of reclaiming pages in
> tiny SWAP_CLUSTER_MAX page chunks and nr_retries is never decremented.

I do not understand this part. How does a smaller reclaim target manages
to have reclaimed > 0 while larger one doesn't?
 
> The docs for memory.reclaim say, "the kernel can over or under reclaim
> from the target cgroup" which this patch was trying to fix. Revert it
> until a less costly solution is found.
> 
> Signed-off-by: T.J. Mercier <tjmercier@google.com>
> ---
>  mm/memcontrol.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index e4c8735e7c85..cee536c97151 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6956,8 +6956,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,
> -					min(nr_to_reclaim - nr_reclaimed, SWAP_CLUSTER_MAX),
> -					GFP_KERNEL, reclaim_options);
> +						nr_to_reclaim - nr_reclaimed,
> +						GFP_KERNEL, reclaim_options);
>  
>  		if (!reclaimed && !nr_retries--)
>  			return -EAGAIN;
> -- 
> 2.43.0.429.g432eaa2c6b-goog
> 

-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2024-01-23  9:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-21 21:44 [PATCH] Revert "mm:vmscan: fix inaccurate reclaim during proactive reclaim" T.J. Mercier
2024-01-23  2:24 ` Yu Zhao
2024-01-23  9:33 ` Michal Hocko [this message]
2024-01-23 13:58   ` T.J. Mercier
2024-01-23 16:19     ` Michal Hocko
2024-01-24 17:14       ` T.J. Mercier
2024-01-23 16:48     ` Johannes Weiner
2024-01-24  7:50       ` Michal Hocko
2024-01-24 17:46       ` T.J. Mercier
2024-01-26 16:34         ` Johannes Weiner
2024-01-26 16:41           ` T.J. Mercier
2024-01-30 20:58             ` T.J. Mercier
2024-01-30 21:56               ` Johannes Weiner
2024-01-27  6:17       ` Yu Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Za-H8NNW9bL-I4gj@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=android-mm@google.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=tjmercier@google.com \
    --cc=yangyifei03@kuaishou.com \
    --cc=yuzhao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.