From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73EB7C43461 for ; Mon, 14 Sep 2020 13:47:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E303C20E65 for ; Mon, 14 Sep 2020 13:47:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E303C20E65 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2A3DC6B0037; Mon, 14 Sep 2020 09:47:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2561A6B0055; Mon, 14 Sep 2020 09:47:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16CDD6B005A; Mon, 14 Sep 2020 09:47:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 008F16B0037 for ; Mon, 14 Sep 2020 09:47:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id AB7B975312 for ; Mon, 14 Sep 2020 13:47:24 +0000 (UTC) X-FDA: 77261794008.27.bears06_5b17afd27109 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 7A3CD1A2595 for ; Mon, 14 Sep 2020 13:47:24 +0000 (UTC) X-HE-Tag: bears06_5b17afd27109 X-Filterd-Recvd-Size: 3325 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Sep 2020 13:47:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9250CB197; Mon, 14 Sep 2020 13:47:37 +0000 (UTC) Date: Mon, 14 Sep 2020 15:47:13 +0200 From: Michal Hocko To: Chunxin Zang Cc: Andrew Morton , Linux Memory Management List , LKML , Muchun Song Subject: Re: [External] Re: [PATCH v2] mm/vmscan: fix infinite loop in drop_slab_node Message-ID: <20200914134713.GS16999@dhcp22.suse.cz> References: <20200909152047.27905-1-zangchunxin@bytedance.com> <20200914093032.GG16999@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 7A3CD1A2595 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 14-09-20 21:25:59, Chunxin Zang wrote: > On Mon, Sep 14, 2020 at 5:30 PM Michal Hocko wrote: >=20 > > 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 recommendati= ons. > Use double of threshold to end the loop. That still means the changelog needs an update =20 > On Thu, Sep 10, 2020 at 1:59 AM Vlastimil Babka wrote: > > > From: Chunxin Zang > > > > > ... > > - 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! > > ... >=20 >=20 >=20 > On Wed 09-09-20 23:20:47, zangchunxin@bytedance.com wrote: > > > From: Chunxin Zang > > > > > > On our server, there are about 10k memcg in one machine. They use m= emory > > > very frequently. When I tigger drop caches=EF=BC=8Cthe 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 g= et > > there. > > >=20 > Yes, it's really an infinite loop. Every loop spends a lot of time. I= n > 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. --=20 Michal Hocko SUSE Labs