From: Chris Down <chris@chrisdown.name>
To: Shakeel Butt <shakeelb@google.com>
Cc: Waiman Long <longman@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Alexey Dobriyan <adobriyan@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-doc@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>, Linux MM <linux-mm@kvack.org>
Subject: Re: [RFC PATCH 1/8] memcg: Enable fine-grained control of over memory.high action
Date: Mon, 17 Aug 2020 17:56:08 +0100 [thread overview]
Message-ID: <20200817165608.GA58383@chrisdown.name> (raw)
In-Reply-To: <CALvZod5V3N3K9-tDoaq=JgkeuAK=0TkRf97Vua0khXL+Lxw+Pg@mail.gmail.com>
Shakeel Butt writes:
>> Sometimes, memory reclaim may not be able to recover memory in a rate
>> that can catch up to the physical memory allocation rate especially
>> when rotating disks are used for swapping or writing dirty pages. In
>> this case, the physical memory consumption will keep on increasing.
>
>Isn't this the real underlying issue? Why not make the guarantees of
>memory.high more strict instead of adding more interfaces and
>complexity?
Oh, thanks Shakeel for bringing this up. I missed this in the original
changelog and I'm surprised that it's mentioned, since we do have protections
against that.
Waiman, we already added artificial throttling if memory reclaim is not
sufficiently achieved in 0e4b01df8659 ("mm, memcg: throttle allocators when
failing reclaim over memory.high"), which has been present since v5.4. This
should significantly inhibit physical memory consumption from increasing. What
problems are you having with that? :-)
next prev parent reply other threads:[~2020-08-17 17:23 UTC|newest]
Thread overview: 58+ 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:44 ` Shakeel Butt
2020-08-17 16:56 ` Chris Down [this message]
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 ` Waiman Long
2020-08-17 14:08 ` [RFC PATCH 4/8] fs/proc: Support a new procfs memctl file Waiman Long
2020-08-17 20:10 ` kernel test robot
2020-08-17 20:10 ` [RFC PATCH] fs/proc: proc_memctl_operations can be static kernel test robot
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 ` 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 15:55 ` Waiman Long
2020-08-17 19:26 ` Michal Hocko
2020-08-18 19:20 ` Waiman Long
2020-08-18 19:20 ` Waiman Long
2020-08-18 9:14 ` peterz
2020-08-18 9:14 ` peterz-wEGCiKHe2LqWVfeAwA7xHQ
2020-08-18 9:26 ` Michal Hocko
2020-08-18 9:26 ` Michal Hocko
2020-08-18 9:59 ` peterz
2020-08-18 9:59 ` peterz-wEGCiKHe2LqWVfeAwA7xHQ
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-18 13:49 ` Johannes Weiner
2020-08-21 19:37 ` Peter Zijlstra
2020-08-21 19:37 ` Peter Zijlstra
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: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-23 2:49 ` Waiman Long
2020-08-18 9:27 ` Chris Down
2020-08-18 9:27 ` Chris Down
2020-08-18 10:04 ` peterz
2020-08-18 12:55 ` Matthew Wilcox
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=20200817165608.GA58383@chrisdown.name \
--to=chris@chrisdown.name \
--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@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=shakeelb@google.com \
--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 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.