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=-7.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 8DBE2C4338F for ; Thu, 19 Aug 2021 09:38:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 35A2460F4C for ; Thu, 19 Aug 2021 09:38:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 35A2460F4C 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 C71356B006C; Thu, 19 Aug 2021 05:38:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C223A6B0071; Thu, 19 Aug 2021 05:38:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B10388D0001; Thu, 19 Aug 2021 05:38:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 93D636B006C for ; Thu, 19 Aug 2021 05:38:35 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 43BA41802E8BC for ; Thu, 19 Aug 2021 09:38:35 +0000 (UTC) X-FDA: 78491330190.22.C99912C Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf03.hostedemail.com (Postfix) with ESMTP id 6D2F83004378 for ; Thu, 19 Aug 2021 09:38:34 +0000 (UTC) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Gr03T2yJszbg1W; Thu, 19 Aug 2021 17:34:45 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggemv704-chm.china.huawei.com (10.3.19.47) 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 17:38:30 +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 17:38:30 +0800 Subject: Re: [PATCH] mm, vmscan: guarantee drop_slab_node() termination To: Vlastimil Babka , Chris Down CC: , Andrew Morton , "Muchun Song" , Michal Hocko , "Matthew Wilcox" , Chunxin Zang References: <20210818152239.25502-1-vbabka@suse.cz> <47437115-1a84-c1d1-d91e-1d23cf7f4a5d@suse.cz> From: Kefeng Wang Message-ID: <76a1baa8-8970-84fb-c4af-f071dfbc88bc@huawei.com> Date: Thu, 19 Aug 2021 17:38:29 +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: <47437115-1a84-c1d1-d91e-1d23cf7f4a5d@suse.cz> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6D2F83004378 X-Stat-Signature: 6ifzw6fhgkizbuhowtzbxp7wsek73b6z Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=huawei.com; spf=pass (imf03.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com X-HE-Tag: 1629365914-925297 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 15:01, Vlastimil Babka wrote: > On 8/19/21 4:55 AM, Kefeng Wang wrote: >> On 2021/8/19 5:48, Chris Down wrote: >>> Vlastimil Babka writes: >>> >>> 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 >>> that even large, continuous periods of reclaim eventually terminates, >>> but I find it hard to reason about -- for example, if there's a lot of >>> parallel activity, that might result in 10 constantly reintroduced >>> pages, or 1000 pages, and it's not immediately obvious that we should >>> treat those differently. >>> >>> What about using MAX_RECLAIM_RETRIES? There's already precedent for >>> using it in non-OOM scenarios, like mem_cgroup_handle_over_high. > It's an option, but then (together with fixed threshold) it ignores how > large the 'freed' value is, as long it's above threshold? Although the > end result will probably not be much different. > >> Yes, we meet this issue too, and we add a max loop limit in >> drop_slab_node() in our kernel, which also could be reconfigured by >> sysctl ;) > Sysctl sounds like an overkill. How do you tune the limit? Any > experience with what scenarios need what limit? This is no clear limit, we do some test, then choose a big limit which is tolerated by our user, and the user could change it dynamically by sysctl interface. The dynamically growing threshold is great, I am very agree with this patch. Like Chris said, the option is that we could also add a max limit then let's the user to make a decision according their scenarios, this is just a option. > > . >