From: Michal Hocko <mhocko@suse.com>
To: Chunxin Zang <zangchunxin@bytedance.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Muchun Song <songmuchun@bytedance.com>
Subject: Re: [External] Re: [PATCH v2] mm/vmscan: fix infinite loop in drop_slab_node
Date: Mon, 14 Sep 2020 15:47:13 +0200 [thread overview]
Message-ID: <20200914134713.GS16999@dhcp22.suse.cz> (raw)
In-Reply-To: <CAKRVAeP1yPDTcdcW+H6EnMrDHsWGNkooGcSyeYWHi8CXCc+u4Q@mail.gmail.com>
On Mon 14-09-20 21:25:59, Chunxin Zang wrote:
> On Mon, Sep 14, 2020 at 5:30 PM Michal Hocko <mhocko@suse.com> wrote:
>
> > The subject is misleading because this patch doesn't fix an infinite
> > loop, right? It just allows the userspace to interrupt the operation.
> >
> >
> Yes, so we are making a separate patch follow Vlastimil's recommendations.
> Use double of threshold to end the loop.
That still means the changelog needs an update
> On Thu, Sep 10, 2020 at 1:59 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> > > From: Chunxin Zang <zangchunxin@bytedance.com>
> > >
> > ...
> > - IMHO it's still worth to bail out in your scenario even without a
> > signal, e.g.
> > by the doubling of threshold. But it can be a separate patch.
> > Thanks!
> > ...
>
>
>
> On Wed 09-09-20 23:20:47, zangchunxin@bytedance.com wrote:
> > > From: Chunxin Zang <zangchunxin@bytedance.com>
> > >
> > > On our server, there are about 10k memcg in one machine. They use memory
> > > very frequently. When I tigger drop caches,the process will infinite loop
> > > in drop_slab_node.
> >
> > Is this really an infinite loop, or it just takes a lot of time to
> > process all the metadata in that setup? If this is really an infinite
> > loop then we should look at it. My current understanding is that the
> > operation would finish at some time it just takes painfully long to get
> > there.
> >
>
> Yes, it's really an infinite loop. Every loop spends a lot of time. In
> this time,
> memcg will alloc/free memory, so the next loop, the total of 'freed'
> always bigger than 10.
I am still not sure I follow. Do you mean that there is somebody
constantly generating more objects to reclaim?
Maybe we are just not agreeing on the definition of an infinite loop but
in my book that means that the final condition can never be met. While a
busy adding new object might indeed cause drop caches to loop for a long
time this is to be expected from that interface as it is supposed to
drop all the cache and that can grow during the operation.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-09-14 13:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 15:20 zangchunxin
2020-09-09 16:09 ` Chris Down
2020-09-09 17:59 ` Vlastimil Babka
2020-09-09 21:47 ` Chris Down
2020-09-09 21:52 ` Matthew Wilcox
2020-09-09 21:56 ` Chris Down
2020-09-09 22:13 ` Vlastimil Babka
2020-09-09 21:49 ` Matthew Wilcox
2020-09-14 9:30 ` Michal Hocko
2020-09-14 13:25 ` [External] " Chunxin Zang
2020-09-14 13:47 ` Michal Hocko [this message]
2020-09-14 15:02 ` Chunxin Zang
2020-09-14 15:17 ` Michal Hocko
2020-09-15 4:23 ` Chunxin Zang
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=20200914134713.GS16999@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=songmuchun@bytedance.com \
--cc=zangchunxin@bytedance.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