From: Michal Hocko <mhocko@kernel.org>
To: Chris Down <chris@chrisdown.name>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] mm, memcg: reclaim more aggressively before high allocator throttling
Date: Thu, 21 May 2020 14:28:14 +0200 [thread overview]
Message-ID: <20200521122814.GN6462@dhcp22.suse.cz> (raw)
In-Reply-To: <20200521112711.GA990580@chrisdown.name>
On Thu 21-05-20 12:27:11, Chris Down wrote:
[...]
> Regardless, you're pushing for different reclaim semantics for memory.high
> than memory.max here, which requires evidence that the current approach
> taken for memory.max is wrong or causing issues.
Sorry, I have skipped over this part. Memory high limit reclaim has
historically acted as a best effort action to throttle the
allocation/charge pace. This would work both if the implementation
simply tried to reclaim down to the high limit or if the reclaim is
proportional to the memory consumption by a specific consumer. We do the
later because it is much easier to establish fairness for. If you want
to change that you somehow have to deal with the fairness problem.
And yes, we do not guarantee any fairness for the hard limit or direct
reclaim in general but that behavior is generally problematic and there
should be really strong arguments to move high limit reclaim that
direction IMHO.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-05-21 12:28 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 14:37 Chris Down
2020-05-20 16:07 ` Michal Hocko
2020-05-20 16:51 ` Johannes Weiner
2020-05-20 17:04 ` Michal Hocko
2020-05-20 17:51 ` Johannes Weiner
2020-05-21 7:32 ` Michal Hocko
2020-05-21 13:51 ` Johannes Weiner
2020-05-21 14:22 ` Johannes Weiner
2020-05-21 14:35 ` Michal Hocko
2020-05-21 15:02 ` Chris Down
2020-05-21 16:38 ` Johannes Weiner
2020-05-21 17:37 ` Michal Hocko
2020-05-21 18:45 ` Johannes Weiner
2020-05-28 16:31 ` Michal Hocko
2020-05-28 16:48 ` Chris Down
2020-05-29 7:31 ` Michal Hocko
2020-05-29 10:08 ` Chris Down
2020-05-29 10:14 ` Michal Hocko
2020-05-28 20:11 ` Johannes Weiner
2020-05-20 20:26 ` Chris Down
2020-05-21 7:19 ` Michal Hocko
2020-05-21 11:27 ` Chris Down
2020-05-21 12:04 ` Michal Hocko
2020-05-21 12:23 ` Chris Down
2020-05-21 12:24 ` Chris Down
2020-05-21 12:37 ` Michal Hocko
2020-05-21 12:57 ` Chris Down
2020-05-21 13:05 ` Chris Down
2020-05-21 13:28 ` Michal Hocko
2020-05-21 13:21 ` Michal Hocko
2020-05-21 13:41 ` Chris Down
2020-05-21 13:58 ` Michal Hocko
2020-05-21 14:22 ` Chris Down
2020-05-21 12:28 ` Michal Hocko [this message]
2020-05-28 18:02 ` Shakeel Butt
2020-05-28 19:48 ` Chris Down
2020-05-28 20:29 ` Johannes Weiner
2020-05-28 21:02 ` Shakeel Butt
2020-05-28 21:14 ` Chris Down
2020-05-29 7:25 ` 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=20200521122814.GN6462@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tj@kernel.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