From: Peter Zijlstra <peterz@infradead.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.com>, Waiman Long <longman@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Alexey Dobriyan <adobriyan@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC PATCH 0/8] memcg: Enable fine-grained per process memory control
Date: Fri, 21 Aug 2020 21:37:16 +0200 [thread overview]
Message-ID: <20200821193716.GU3982@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20200818134900.GA829964@cmpxchg.org>
On Tue, Aug 18, 2020 at 09:49:00AM -0400, Johannes Weiner wrote:
> On Tue, Aug 18, 2020 at 12:18:44PM +0200, peterz@infradead.org wrote:
> > What you need is a feeback loop against the rate of freeing pages, and
> > when you near the saturation point, the allocation rate should exactly
> > match the freeing rate.
>
> IO throttling solves a slightly different problem.
>
> IO occurs in parallel to the workload's execution stream, and you're
> trying to take the workload from dirtying at CPU speed to rate match
> to the independent IO stream.
>
> With memory allocations, though, freeing happens from inside the
> execution stream of the workload. If you throttle allocations, you're
For a single task, but even then you're making the argument that we need
to allocate memory to free memory, and we all know where that gets us.
But we're actually talking about a cgroup here, which is a collection of
tasks all doing things in parallel.
> most likely throttling the freeing rate as well. And you'll slow down
> reclaim scanning by the same amount as the page references, so it's
> not making reclaim more successful either. The alloc/use/free
> (im)balance is an inherent property of the workload, regardless of the
> speed you're executing it at.
Arguably seeing the rate drop to near 0 is a very good point to consider
running cgroup-OOM.
next prev parent reply other threads:[~2020-08-21 19:37 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-17 14:08 [RFC PATCH 0/8] memcg: Enable fine-grained per process memory control Waiman Long
2020-08-17 14:08 ` [RFC PATCH 1/8] memcg: Enable fine-grained control of over memory.high action Waiman Long
2020-08-17 14:30 ` Chris Down
2020-08-17 15:38 ` Waiman Long
2020-08-17 16:11 ` Chris Down
2020-08-17 16:44 ` Shakeel Butt
2020-08-17 16:56 ` Chris Down
2020-08-18 19:12 ` Waiman Long
2020-08-18 19:14 ` Waiman Long
2020-08-17 14:08 ` [RFC PATCH 2/8] memcg, mm: Return ENOMEM or delay if memcg_over_limit Waiman Long
2020-08-17 14:08 ` [RFC PATCH 3/8] memcg: Allow the use of task RSS memory as over-high action trigger Waiman Long
2020-08-17 14:08 ` [RFC PATCH 4/8] fs/proc: Support a new procfs memctl file Waiman Long
2020-08-17 14:08 ` [RFC PATCH 5/8] memcg: Allow direct per-task memory limit checking Waiman Long
2020-08-17 14:08 ` [RFC PATCH 6/8] memcg: Introduce additional memory control slowdown if needed Waiman Long
2020-08-17 14:08 ` [RFC PATCH 7/8] memcg: Enable logging of memory control mitigation action Waiman Long
2020-08-17 14:08 ` [RFC PATCH 8/8] memcg: Add over-high action prctl() documentation Waiman Long
2020-08-17 15:26 ` [RFC PATCH 0/8] memcg: Enable fine-grained per process memory control Michal Hocko
2020-08-17 15:55 ` Waiman Long
2020-08-17 19:26 ` Michal Hocko
2020-08-18 19:20 ` Waiman Long
2020-08-18 9:14 ` peterz
2020-08-18 9:26 ` Michal Hocko
2020-08-18 9:59 ` peterz
2020-08-18 10:05 ` Michal Hocko
2020-08-18 10:18 ` peterz
2020-08-18 10:30 ` Michal Hocko
2020-08-18 10:36 ` peterz
2020-08-18 13:49 ` Johannes Weiner
2020-08-21 19:37 ` Peter Zijlstra [this message]
2020-08-24 16:58 ` Johannes Weiner
2020-09-07 11:47 ` Chris Down
2020-09-09 11:53 ` Michal Hocko
2020-08-18 10:17 ` Chris Down
2020-08-18 10:26 ` peterz
2020-08-18 10:35 ` Chris Down
2020-08-23 2:49 ` Waiman Long
2020-08-18 9:27 ` Chris Down
2020-08-18 10:04 ` peterz
2020-08-18 12:55 ` Matthew Wilcox
2020-08-20 6:11 ` Dave Chinner
2020-08-18 19:30 ` Waiman Long
2020-08-18 19:27 ` Waiman Long
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=20200821193716.GU3982@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=hannes@cmpxchg.org \
--cc=juri.lelli@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=vincent.guittot@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).