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=-12.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 23022C4338F for ; Thu, 19 Aug 2021 02:55:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 93B5260F35 for ; Thu, 19 Aug 2021 02:55:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 93B5260F35 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BC3106B006C; Wed, 18 Aug 2021 22:55:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B55E26B0071; Wed, 18 Aug 2021 22:55:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3AF78D0001; Wed, 18 Aug 2021 22:55:44 -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 8656B6B006C for ; Wed, 18 Aug 2021 22:55:44 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 19D80180397E7 for ; Thu, 19 Aug 2021 02:55:44 +0000 (UTC) X-FDA: 78490315008.06.60FF1EA Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf12.hostedemail.com (Postfix) with ESMTP id 2FF2410079B1 for ; Thu, 19 Aug 2021 02:55:43 +0000 (UTC) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.53]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4GqqBV55Ynz1CXK0; Thu, 19 Aug 2021 10:55:14 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 19 Aug 2021 10:55:39 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 19 Aug 2021 10:55:39 +0800 Subject: Re: [PATCH] mm, vmscan: guarantee drop_slab_node() termination To: Chris Down , Vlastimil Babka CC: , Andrew Morton , "Muchun Song" , Michal Hocko , "Matthew Wilcox" , Chunxin Zang References: <20210818152239.25502-1-vbabka@suse.cz> From: Kefeng Wang Message-ID: Date: Thu, 19 Aug 2021 10:55:38 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=none) header.from=huawei.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2FF2410079B1 X-Stat-Signature: wbsz73cactmi9x7q3yn39mfrdcjs6bci X-HE-Tag: 1629341743-250863 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 2021/8/19 5:48, Chris Down wrote: > Vlastimil Babka writes: >> @@ -948,7 +949,7 @@ void drop_slab_node(int nid) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fre= ed +=3D shrink_slab(GFP_KERNEL, nid, memcg, 0); >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } while ((memcg =3D mem_cgr= oup_iter(NULL, memcg, NULL)) !=3D NULL); >> -=C2=A0=C2=A0=C2=A0 } while (freed > 10); >> +=C2=A0=C2=A0=C2=A0 } while ((freed >> shift++) > 0); > > I think this is a good idea, thanks for bringing it up :-) > > I'm not sure about the bitshift idea, though. It certainly makes sure=20 > that even large, continuous periods of reclaim eventually terminates,=20 > but I find it hard to reason about -- for example, if there's a lot of=20 > parallel activity, that might result in 10 constantly reintroduced=20 > pages, or 1000 pages, and it's not immediately obvious that we should=20 > treat those differently. > > What about using MAX_RECLAIM_RETRIES? There's already precedent for=20 > using it in non-OOM scenarios, like mem_cgroup_handle_over_high. Yes, we meet this issue too, and we add a max loop limit in=20 drop_slab_node() in our kernel, which also could be reconfigured by=20 sysctl ;) > > . >