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.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 C7149C4338F for ; Thu, 19 Aug 2021 13:21:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6C25D6112E for ; Thu, 19 Aug 2021 13:21:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6C25D6112E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B28D86B006C; Thu, 19 Aug 2021 09:21:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD8B76B0071; Thu, 19 Aug 2021 09:21:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C7836B0072; Thu, 19 Aug 2021 09:21:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id 837ED6B006C for ; Thu, 19 Aug 2021 09:21:12 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 250371802BC7F for ; Thu, 19 Aug 2021 13:21:12 +0000 (UTC) X-FDA: 78491891184.32.F4E019C Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by imf03.hostedemail.com (Postfix) with ESMTP id 79BA33008990 for ; Thu, 19 Aug 2021 13:21:11 +0000 (UTC) Received: by mail-wm1-f49.google.com with SMTP id f9-20020a05600c1549b029025b0f5d8c6cso6798346wmg.4 for ; Thu, 19 Aug 2021 06:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=sZnKThSbtWbHumx/fjNEnnLqIK0ldBlSCfvb8pRSaeY=; b=C7+K+QCmZM+g1ZVNqC5orv9STukeQvrg9twj+RzkokBGWMnyzkGO+UNniGQSWlHFxC jFq7Mh+P2iYhfpl1sttMKslTD2B91okcOy8MvlPmpZFbQa0D2WUCkVACRgPSvJl8t7gq 5s1AgUYGoyxJWkw2cg3S10/leI+kmys5/x994= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=sZnKThSbtWbHumx/fjNEnnLqIK0ldBlSCfvb8pRSaeY=; b=otgWi9ISftZ2Zkx2gOrhCY5h408jH8xNVuF+Nt8iaPAGj87HJ+4IXN75+y9cuv2kx4 9/VFDCPQ46skPN5LaG6cYTvW2LrdYjjYuIE056rvGvXZ1Yi+IFFpt8p3iQOmVo63rZ5+ +O22+7j2AjtCBoXJ+INP+LLNG4MprGb8YSbIzaR+R3689cPq5J3tORmKbslh/3VWQM8E uG1Sm1wJZ8k6U74EIUecqv+U0cWi89JVmiULrLFd8paunk0KoaTK5zQR9Q1n/1UMepBW 1h9yHP2kf+VMB/jXDLDWSZOKOU0YPlUMwsG1szBqp93bWMEXxXACi8+GH79UkPwaWJm5 qm+Q== X-Gm-Message-State: AOAM532iBaE1BA0+v2QkAaVPwtSJJE2S/MZxzJ4m28xq/+EyXeEP9pIg 0N6jV8cPXFZs7iHdTVUd6KPc9g== X-Google-Smtp-Source: ABdhPJzba9mibKhYE4wWQUKFCnMGRgUMJPozNpbS2wRi4Tle4+paPqz1TbjEsakaq4RLJTHod977Bw== X-Received: by 2002:a7b:cb44:: with SMTP id v4mr13904464wmj.169.1629379270119; Thu, 19 Aug 2021 06:21:10 -0700 (PDT) Received: from localhost (82-69-42-66.dsl.in-addr.zen.co.uk. [82.69.42.66]) by smtp.gmail.com with ESMTPSA id s12sm2947754wru.41.2021.08.19.06.21.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 06:21:09 -0700 (PDT) Date: Thu, 19 Aug 2021 14:21:08 +0100 From: Chris Down To: Vlastimil Babka Cc: Kefeng Wang , linux-mm@kvack.org, Andrew Morton , Muchun Song , Michal Hocko , Matthew Wilcox , Chunxin Zang Subject: Re: [PATCH] mm, vmscan: guarantee drop_slab_node() termination Message-ID: References: <20210818152239.25502-1-vbabka@suse.cz> <47437115-1a84-c1d1-d91e-1d23cf7f4a5d@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <47437115-1a84-c1d1-d91e-1d23cf7f4a5d@suse.cz> User-Agent: Mutt/2.1.1 (e2a89abc) (2021-07-12) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chrisdown.name header.s=google header.b=C7+K+QCm; dmarc=pass (policy=none) header.from=chrisdown.name; spf=pass (imf03.hostedemail.com: domain of chris@chrisdown.name designates 209.85.128.49 as permitted sender) smtp.mailfrom=chris@chrisdown.name X-Stat-Signature: wxciswpynuxsgyar7w77n7fa1yj9jwmp X-Rspamd-Queue-Id: 79BA33008990 X-Rspamd-Server: rspam01 X-HE-Tag: 1629379271-130731 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: Vlastimil Babka writes: >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. Yeah, but we already draw the line at 10 right now. `freed > 10 && retries < MAX_RECLAIM_RETRIES` seems easier to reason about, at least to me, and stays closer to the current behaviour while providing a definitive point of loop termination. >> 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? sysctls in mm tend to mean we didn't think hard enough about how things should work and just punted it to the user :-) So I agree with you that I'd rather not have a sysctl, and just go the MAX_RECLAIM_RETRIES route. After that I'll happily add my Acked-by.