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 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 1CEFFC433DF for ; Wed, 26 Aug 2020 12:07:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DCE4920786 for ; Wed, 26 Aug 2020 12:07:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DCE4920786 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 85CB76B000C; Wed, 26 Aug 2020 08:07:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80D906B000D; Wed, 26 Aug 2020 08:07:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 724FE6B000E; Wed, 26 Aug 2020 08:07:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 5B5056B000C for ; Wed, 26 Aug 2020 08:07:46 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 16E35181AEF0B for ; Wed, 26 Aug 2020 12:07:46 +0000 (UTC) X-FDA: 77192595732.01.grain94_610b33227064 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id B1E1E10046D49 for ; Wed, 26 Aug 2020 12:07:42 +0000 (UTC) X-HE-Tag: grain94_610b33227064 X-Filterd-Recvd-Size: 2489 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Wed, 26 Aug 2020 12:07:42 +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 37BC4AF2F; Wed, 26 Aug 2020 12:08:12 +0000 (UTC) Date: Wed, 26 Aug 2020 14:07:40 +0200 From: Michal Hocko To: xunlei Cc: Johannes Weiner , Andrew Morton , Vladimir Davydov , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: memcg: Fix memcg reclaim soft lockup Message-ID: <20200826120740.GP22869@dhcp22.suse.cz> References: <1598426822-93737-1-git-send-email-xlpang@linux.alibaba.com> <20200826081102.GM22869@dhcp22.suse.cz> <99efed0e-050a-e313-46ab-8fe6228839d5@linux.alibaba.com> <20200826110015.GO22869@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B1E1E10046D49 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Wed 26-08-20 20:00:47, xunlei wrote: > On 2020/8/26 =E4=B8=8B=E5=8D=887:00, Michal Hocko wrote: > > On Wed 26-08-20 18:41:18, xunlei wrote: > >> On 2020/8/26 =E4=B8=8B=E5=8D=884:11, Michal Hocko wrote: > >>> On Wed 26-08-20 15:27:02, Xunlei Pang wrote: > >>>> We've met softlockup with "CONFIG_PREEMPT_NONE=3Dy", when > >>>> the target memcg doesn't have any reclaimable memory. > >>> > >>> Do you have any scenario when this happens or is this some sort of = a > >>> test case? > >> > >> It can happen on tiny guest scenarios. > >=20 > > OK, you made me more curious. If this is a tiny guest and this is a h= ard > > limit reclaim path then we should trigger an oom killer which should > > kill the offender and that in turn bail out from the try_charge lopp > > (see should_force_charge). So how come this repeats enough in your se= tup > > that it causes soft lockups? > >=20 >=20 > should_force_charge() is false, the current trapped in endless loop is > not the oom victim. How is that possible? If the oom killer kills a task and that doesn't resolve the oom situation then it would go after another one until all tasks are killed. Or is your task living outside of the memcg it tries to charge? --=20 Michal Hocko SUSE Labs