From: Michal Hocko <mhocko@kernel.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>, Chris Down <chris@chrisdown.name>,
Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH 0/3] mm: improve proportional memcg protection
Date: Tue, 28 Apr 2020 14:42:22 +0200 [thread overview]
Message-ID: <20200428124222.GR28637@dhcp22.suse.cz> (raw)
In-Reply-To: <CALOAHbBDXRXX9c-svbuuoBRtAZtfz0FLz-ma2K+PkFeVC2yQGA@mail.gmail.com>
On Tue 28-04-20 20:25:49, Yafang Shao wrote:
> On Tue, Apr 28, 2020 at 6:43 PM Michal Hocko <mhocko@kernel.org> wrote:
[...]
> > [...]
> > > > So it would be really more helpful to not insist on unrelated
> > > > implementation details and focus on two things 1) split up the effective
> > > > values calculation from the predicate (cleanup without any functional
> > > > changes) 2) make the calculation more robust against racing reclaimers.
> > > >
> > >
> > > Another thing should be considered as well, 0) don't access
> > > memroy.emin and elow in get_scan_count().
> >
> > If you can achieve the gradual transition over protections by other
> > means then I am really interested in more details.
>
> sc->protection
I believe I have covered this one already.
> I make my statement again - accessing the realy fragile emin & elow
> in very deep reclaiming code is a totally horrible HACK, that is the
> root of all evil.
Both me and Johannes tried to explain that we simply have to calculate
effective values for the whole reclaim tree. That has to be done
somehow. Caching effective values is a tricky solution but I am not
really aware of another without requiring to allocate storage for
intermediate results. Maybe there is a way to make that storage really
small to live on the stack or some other tricks. If you do not have any
clever ideas how to achieve that then we have to live with the caching
at the memcg level. And then we have to deal with 2) mentioned above.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2020-04-28 12:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-25 15:24 Yafang Shao
2020-04-25 15:24 ` [PATCH 1/3] mm: move struct scan_control into internal.h Yafang Shao
2020-04-25 15:24 ` [PATCH 2/3] mm: add reclaim context as a new parameter in mem_cgroup_protected() Yafang Shao
2020-04-25 15:24 ` [PATCH 3/3] mm: improvements on memcg protection functions Yafang Shao
2020-04-27 9:40 ` Michal Hocko
2020-04-27 10:09 ` Yafang Shao
2020-04-27 10:50 ` Michal Hocko
2020-04-27 11:06 ` Yafang Shao
2020-04-27 11:24 ` Michal Hocko
2020-04-27 11:32 ` Yafang Shao
2020-04-27 17:05 ` [PATCH 0/3] mm: improve proportional memcg protection Johannes Weiner
2020-04-28 1:45 ` Yafang Shao
2020-04-28 3:37 ` Johannes Weiner
2020-04-28 6:00 ` Yafang Shao
2020-04-28 8:05 ` Michal Hocko
2020-04-28 8:22 ` Yafang Shao
2020-04-28 10:43 ` Michal Hocko
2020-04-28 12:25 ` Yafang Shao
2020-04-28 12:42 ` Michal Hocko [this message]
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=20200428124222.GR28637@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=chris@chrisdown.name \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=laoar.shao@gmail.com \
--cc=linux-mm@kvack.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