linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yafang Shao <laoar.shao@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Yang Shi <yang.shi@linux.alibaba.com>,
	Adric Blake <promarbler14@gmail.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Kirill Tkhai <ktkhai@virtuozzo.com>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	 Mel Gorman <mgorman@techsingularity.net>,
	Linux MM <linux-mm@kvack.org>,
	 LKML <linux-kernel@vger.kernel.org>
Subject: Re: WARNINGs in set_task_reclaim_state with memory cgroup and full memory usage
Date: Tue, 27 Aug 2019 20:19:34 +0800	[thread overview]
Message-ID: <CALOAHbDbNxg1xxZAT0rf3=46DrM1PV2YEDEP6F9HMU9JvgvESA@mail.gmail.com> (raw)
In-Reply-To: <20190827120335.GA7538@dhcp22.suse.cz>

On Tue, Aug 27, 2019 at 8:03 PM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 27-08-19 19:56:16, Yafang Shao wrote:
> > On Tue, Aug 27, 2019 at 7:50 PM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > On Tue 27-08-19 19:43:49, Yafang Shao wrote:
> > > > On Tue, Aug 27, 2019 at 6:43 PM Michal Hocko <mhocko@kernel.org> wrote:
> > > > >
> > > > > If there are no objection to the patch I will post it as a standalong
> > > > > one.
> > > >
> > > > I have no objection to your patch. It could fix the issue.
> > > >
> > > > I still think that it is not proper to use a new scan_control here as
> > > > it breaks the global reclaim context.
> > > >
> > > > This context switch from global reclaim to memcg reclaim is very
> > > > subtle change to the subsequent processing, that may cause some
> > > > unexpected behavior.
> > >
> > > Why would it break it? Could you be more specific please?
> > >
> >
> > Hmm, I have explained it when replying to  Hillf's patch.
> > The most suspcious one is settting target_mem_cgroup here, because we
> > only use it to judge whether it is in global reclaim.
> > While the memcg softlimit reclaim is really in global reclaims.
>
> But we are reclaim the target_mem_cgroup hierarchy. This is the whole
> point of the soft reclaim. Push down that hierarchy below the configured
> limit. And that is why we absolutely have to switch the reclaim context.
>

One obvious issue is the reclaim couters may not correct.
See shrink_inactive_list().
The pages relcaimed in memcg softlimit will not be counted to
PGSCAN_{DIRECT, KSWAPD} and
PGSTEAL_{DIRECT, KSWAPD}.
That may cause some misleading. For example, if these counters are not
changed, we will think that direct relcaim doesn't occur, while it
really occurs.

May issues are also in  some other code around the usage of
global_reclaim(). I'm not sure of it.

> > Another example the reclaim_idx, if is not same with reclaim_idx in
> > page allocation context, the reclaimed pages may not be used by the
> > allocator, especially in the direct reclaim.
>
> Again, we do not care about that as well. All we care about is to
> reclaim _some_ memory to get below the soft limit. This is the semantic
> that is not really great but this is how the Soft reclaim has
> traditionally worked and why we keep claiming that people shouldn't
> really use it. It does lead to over reclaim and that is a design rather
> than a bug.
>
> > And some other things in scan_control.
>
> Like?
> --
> Michal Hocko
> SUSE Labs
>


  reply	other threads:[~2019-08-27 12:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23 22:00 Adric Blake
2019-08-24  1:03 ` Yang Shi
2019-08-26 10:55   ` Michal Hocko
2019-08-27 10:43     ` Michal Hocko
2019-08-27 11:43       ` Yafang Shao
2019-08-27 11:50         ` Michal Hocko
2019-08-27 11:56           ` Yafang Shao
2019-08-27 12:03             ` Michal Hocko
2019-08-27 12:19               ` Yafang Shao [this message]
2019-08-27 12:55                 ` Michal Hocko
2019-08-27 17:12       ` Yang Shi
2019-08-24  2:57 Hillf Danton
2019-08-24  3:35 ` Yafang Shao

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='CALOAHbDbNxg1xxZAT0rf3=46DrM1PV2YEDEP6F9HMU9JvgvESA@mail.gmail.com' \
    --to=laoar.shao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.m.jordan@oracle.com \
    --cc=hannes@cmpxchg.org \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=promarbler14@gmail.com \
    --cc=yang.shi@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox