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>,
	Efly Young <yangyifei03@kuaishou.com>,
	android-mm@google.com, yuzhao@google.com, mkoutny@suse.com,
	Yosry Ahmed <yosryahmed@google.com>,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] mm: memcg: Use larger batches for proactive reclaim
Date: Mon, 5 Feb 2024 22:16:34 +0100	[thread overview]
Message-ID: <ZcFQMru5_oATGbuP@tiehlicka> (raw)
In-Reply-To: <CABdmKX0t1LXj80Awe20TrmY5gQB6v2E4bGfW8WXr2i84o+k6ow@mail.gmail.com>

On Mon 05-02-24 12:47:47, T.J. Mercier wrote:
> On Mon, Feb 5, 2024 at 12:36 PM Michal Hocko <mhocko@suse.com> wrote:
[...]
> > This of something like
> > timeout $TIMEOUT echo $TARGET > $MEMCG_PATH/memory.reclaim
> > where timeout acts as a stop gap if the reclaim cannot finish in
> > TIMEOUT.
> 
> Yeah I get the desired behavior, but using sc->nr_reclaimed to achieve
> it is what's bothering me.

I am not really happy about this subtlety. If we have a better way then
let's do it. Better in its own patch, though.

> It's already wired up that way though, so if you want to make this
> change now then I can try to test for the difference using really
> large reclaim targets.

Yes, please. If you want it a separate patch then no objection from me
of course. If you do no like the nr_to_reclaim bailout then maybe we can
go with a simple break out flag in scan_control.

Thanks!
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2024-02-05 21:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02 23:38 [PATCH v3] mm: memcg: Use larger batches for proactive reclaim T.J. Mercier
2024-02-04 16:17 ` Shakeel Butt
2024-02-05 10:01 ` Michal Koutný
2024-02-05 10:40 ` Michal Hocko
2024-02-05 19:29   ` T.J. Mercier
2024-02-05 19:40     ` Michal Hocko
2024-02-05 20:26       ` T.J. Mercier
2024-02-05 20:36         ` Michal Hocko
2024-02-05 20:47           ` T.J. Mercier
2024-02-05 21:16             ` Michal Hocko [this message]
2024-02-06  4:01               ` T.J. Mercier
2024-02-06  8:58                 ` Michal Hocko
2024-02-19 12:11                   ` Michal Hocko
2024-02-19 16:39                     ` T.J. Mercier
2024-02-19 19:33                       ` Michal Hocko

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=ZcFQMru5_oATGbuP@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=mkoutny@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=tjmercier@google.com \
    --cc=yangyifei03@kuaishou.com \
    --cc=yosryahmed@google.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.