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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 6433EC433E9 for ; Wed, 10 Mar 2021 18:25:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 340D964EE6 for ; Wed, 10 Mar 2021 18:25:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232330AbhCJSYb (ORCPT ); Wed, 10 Mar 2021 13:24:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233130AbhCJSYU (ORCPT ); Wed, 10 Mar 2021 13:24:20 -0500 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43ECBC061760 for ; Wed, 10 Mar 2021 10:24:20 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id p15so26797060ljc.13 for ; Wed, 10 Mar 2021 10:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uM8pUZ0KtpIP4tmwMWGoiI2kI1p+H+zJasTko8V61Mw=; b=qK+Eak/IUin0xvRSRy/doM8DVPq6tgbzFJp2RqOhLyzg39iiQj/3VtuCR4uh4V0taP NsJH1HKbhu0DA0STZiobO4FRclLpJEt1UW0057VMAwvwB0/2Lvpz5cfmnFJqoyJrkDK/ qnXIiaQfNmk+AncdFYYrid1iADXijko36+wbl2oEEZOV/VkpbNPsp1eGwRqPOtkBa7w2 N+TD887AuLjcacHbPDsBdHa03V9wJo3qc5Zl7T8H5uqlUZziiDR8MCOBQXh131LMdOff 0jh07+UhYLy4Kwk5TlToV6EcfCjmg03X+58fhcS4z17+rkIb17h+VG85eIIeBDMRwJW7 Ipow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uM8pUZ0KtpIP4tmwMWGoiI2kI1p+H+zJasTko8V61Mw=; b=SEVnPWnPd7Pp5DtY1hNZrZkxNSe7UOQ0Ny6/mDIgCOoI/cyhjbYkTNYuX7jlIBPJlv xUjccUpvto/p0Emycubsj8sr+6VLuqsKhR63geCQiyfxafPvtW/nbDeRJiyIs9nfK8Ps 8rOXtrN6EX+gQk309cqZouUYY9nRkj5+OO2Lufc2zE7RWS+PNKOohfmIaKGw+pPPLWc7 +zXepokeivKzmpvjbd+DUJ+vs/qOHfya7QjdMesKT0bWx26EU2C7MmwQpugNLUjghIrp lcNQl0dYYUh1dBtK2St4wjCX3Vf7SOSfUbRsZ8GInAJKSyDgQDxJJNm4IPLTTtPKhnV9 eybA== X-Gm-Message-State: AOAM532OWaks9FnNRfiOiwcf4qJ7vuQrXlLD38nki/2+XTuw37lCChY7 im8o6EPMnP70KcIRbdj0JbJSxNHXy54Sl60PQe/XWg== X-Google-Smtp-Source: ABdhPJwd9A8937MRDsobC/NbdnlGRgLFg6wQJm3RHO2xVNlco62TixObhQVwvQCnX4kNOVtcvAu23vTVZ6Boxb6yHMc= X-Received: by 2002:a2e:8984:: with SMTP id c4mr2444913lji.456.1615400658479; Wed, 10 Mar 2021 10:24:18 -0800 (PST) MIME-Version: 1.0 References: <20210310174603.5093-1-shy828301@gmail.com> <20210310174603.5093-14-shy828301@gmail.com> In-Reply-To: <20210310174603.5093-14-shy828301@gmail.com> From: Shakeel Butt Date: Wed, 10 Mar 2021 10:24:06 -0800 Message-ID: Subject: Re: [v9 PATCH 13/13] mm: vmscan: shrink deferred objects proportional to priority To: Yang Shi Cc: Roman Gushchin , Kirill Tkhai , Vlastimil Babka , Dave Chinner , Johannes Weiner , Michal Hocko , Andrew Morton , Linux MM , linux-fsdevel , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 10, 2021 at 9:46 AM Yang Shi wrote: > > The number of deferred objects might get windup to an absurd number, and it > results in clamp of slab objects. It is undesirable for sustaining workingset. > > So shrink deferred objects proportional to priority and cap nr_deferred to twice > of cache items. > > The idea is borrowed from Dave Chinner's patch: > https://lore.kernel.org/linux-xfs/20191031234618.15403-13-david@fromorbit.com/ > > Tested with kernel build and vfs metadata heavy workload in our production > environment, no regression is spotted so far. Did you run both of these workloads in the same cgroup or separate cgroups? > > Signed-off-by: Yang Shi > --- > mm/vmscan.c | 46 +++++++++++----------------------------------- > 1 file changed, 11 insertions(+), 35 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 9a2dfeaa79f4..6a0a91b23597 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -662,7 +662,6 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, > */ > nr = xchg_nr_deferred(shrinker, shrinkctl); > > - total_scan = nr; > if (shrinker->seeks) { > delta = freeable >> priority; > delta *= 4; > @@ -676,37 +675,9 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, > delta = freeable / 2; > } > > + total_scan = nr >> priority; > total_scan += delta; > - if (total_scan < 0) { > - pr_err("shrink_slab: %pS negative objects to delete nr=%ld\n", > - shrinker->scan_objects, total_scan); > - total_scan = freeable; > - next_deferred = nr; > - } else > - next_deferred = total_scan; > - > - /* > - * We need to avoid excessive windup on filesystem shrinkers > - * due to large numbers of GFP_NOFS allocations causing the > - * shrinkers to return -1 all the time. This results in a large > - * nr being built up so when a shrink that can do some work > - * comes along it empties the entire cache due to nr >>> > - * freeable. This is bad for sustaining a working set in > - * memory. > - * > - * Hence only allow the shrinker to scan the entire cache when > - * a large delta change is calculated directly. > - */ > - if (delta < freeable / 4) > - total_scan = min(total_scan, freeable / 2); > - > - /* > - * Avoid risking looping forever due to too large nr value: > - * never try to free more than twice the estimate number of > - * freeable entries. > - */ > - if (total_scan > freeable * 2) > - total_scan = freeable * 2; > + total_scan = min(total_scan, (2 * freeable)); > > trace_mm_shrink_slab_start(shrinker, shrinkctl, nr, > freeable, delta, total_scan, priority); > @@ -745,10 +716,15 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, > cond_resched(); > } > > - if (next_deferred >= scanned) > - next_deferred -= scanned; > - else > - next_deferred = 0; > + /* > + * The deferred work is increased by any new work (delta) that wasn't > + * done, decreased by old deferred work that was done now. > + * > + * And it is capped to two times of the freeable items. > + */ > + next_deferred = max_t(long, (nr + delta - scanned), 0); > + next_deferred = min(next_deferred, (2 * freeable)); > + > /* > * move the unused scan count back into the shrinker in a > * manner that handles concurrent updates. > -- > 2.26.2 > 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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL 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 2D143C433DB for ; Wed, 10 Mar 2021 18:24:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BC79264F9A for ; Wed, 10 Mar 2021 18:24:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC79264F9A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 353108D01F8; Wed, 10 Mar 2021 13:24:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DC188D01ED; Wed, 10 Mar 2021 13:24:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12E178D01F8; Wed, 10 Mar 2021 13:24:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id E6F348D01ED for ; Wed, 10 Mar 2021 13:24:20 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id ABCBF8128 for ; Wed, 10 Mar 2021 18:24:20 +0000 (UTC) X-FDA: 77904789480.14.117590E Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf22.hostedemail.com (Postfix) with ESMTP id 016DFC0007C1 for ; Wed, 10 Mar 2021 18:24:17 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id 2so26858626ljr.5 for ; Wed, 10 Mar 2021 10:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uM8pUZ0KtpIP4tmwMWGoiI2kI1p+H+zJasTko8V61Mw=; b=qK+Eak/IUin0xvRSRy/doM8DVPq6tgbzFJp2RqOhLyzg39iiQj/3VtuCR4uh4V0taP NsJH1HKbhu0DA0STZiobO4FRclLpJEt1UW0057VMAwvwB0/2Lvpz5cfmnFJqoyJrkDK/ qnXIiaQfNmk+AncdFYYrid1iADXijko36+wbl2oEEZOV/VkpbNPsp1eGwRqPOtkBa7w2 N+TD887AuLjcacHbPDsBdHa03V9wJo3qc5Zl7T8H5uqlUZziiDR8MCOBQXh131LMdOff 0jh07+UhYLy4Kwk5TlToV6EcfCjmg03X+58fhcS4z17+rkIb17h+VG85eIIeBDMRwJW7 Ipow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uM8pUZ0KtpIP4tmwMWGoiI2kI1p+H+zJasTko8V61Mw=; b=IqG8h0WCWhRXh/GWEVjW5mpMBq12Z8fNto6yvQXKVk0dGiAChww+cvIS0F/Cm0sS/7 nal01jf88tfNhyPY2MBtqrXKdujtzgmwE34inPqjNs60w5EvVK+c1GDBuiMyEzE/eixm sswcHE6z9Ok+M0519iGhShgGcQMzqWTkj9qTYntDxS4BIefUKLEWvi0YFamj1xxcRpVe oUkaI9UFv8mPvsJaqp2jA6yxDo/NH4yF8tQEADFNS9/euNrTxEr4VBFNkm9av2tW3teQ /vvUcNS/UaGfUCqLe7YBpqWfv0SH8EuOhyjHxEvnN09ZHuDK6Wb48yMNENd7WpqLhX/N J61Q== X-Gm-Message-State: AOAM531fFXu0kiMdtMNmicCzK5GTZkeSK3BPURakQAiu0WKwd2S9OIDj iFbC8GgxbfTfFljT4saCwhMGIMX6Ys220oJPwjsPFg== X-Google-Smtp-Source: ABdhPJwd9A8937MRDsobC/NbdnlGRgLFg6wQJm3RHO2xVNlco62TixObhQVwvQCnX4kNOVtcvAu23vTVZ6Boxb6yHMc= X-Received: by 2002:a2e:8984:: with SMTP id c4mr2444913lji.456.1615400658479; Wed, 10 Mar 2021 10:24:18 -0800 (PST) MIME-Version: 1.0 References: <20210310174603.5093-1-shy828301@gmail.com> <20210310174603.5093-14-shy828301@gmail.com> In-Reply-To: <20210310174603.5093-14-shy828301@gmail.com> From: Shakeel Butt Date: Wed, 10 Mar 2021 10:24:06 -0800 Message-ID: Subject: Re: [v9 PATCH 13/13] mm: vmscan: shrink deferred objects proportional to priority To: Yang Shi Cc: Roman Gushchin , Kirill Tkhai , Vlastimil Babka , Dave Chinner , Johannes Weiner , Michal Hocko , Andrew Morton , Linux MM , linux-fsdevel , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 016DFC0007C1 X-Stat-Signature: eqzybu1jjdydq3ag5bq7a754jnd1in93 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf22; identity=mailfrom; envelope-from=""; helo=mail-lj1-f170.google.com; client-ip=209.85.208.170 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615400657-997847 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, Mar 10, 2021 at 9:46 AM Yang Shi wrote: > > The number of deferred objects might get windup to an absurd number, and it > results in clamp of slab objects. It is undesirable for sustaining workingset. > > So shrink deferred objects proportional to priority and cap nr_deferred to twice > of cache items. > > The idea is borrowed from Dave Chinner's patch: > https://lore.kernel.org/linux-xfs/20191031234618.15403-13-david@fromorbit.com/ > > Tested with kernel build and vfs metadata heavy workload in our production > environment, no regression is spotted so far. Did you run both of these workloads in the same cgroup or separate cgroups? > > Signed-off-by: Yang Shi > --- > mm/vmscan.c | 46 +++++++++++----------------------------------- > 1 file changed, 11 insertions(+), 35 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 9a2dfeaa79f4..6a0a91b23597 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -662,7 +662,6 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, > */ > nr = xchg_nr_deferred(shrinker, shrinkctl); > > - total_scan = nr; > if (shrinker->seeks) { > delta = freeable >> priority; > delta *= 4; > @@ -676,37 +675,9 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, > delta = freeable / 2; > } > > + total_scan = nr >> priority; > total_scan += delta; > - if (total_scan < 0) { > - pr_err("shrink_slab: %pS negative objects to delete nr=%ld\n", > - shrinker->scan_objects, total_scan); > - total_scan = freeable; > - next_deferred = nr; > - } else > - next_deferred = total_scan; > - > - /* > - * We need to avoid excessive windup on filesystem shrinkers > - * due to large numbers of GFP_NOFS allocations causing the > - * shrinkers to return -1 all the time. This results in a large > - * nr being built up so when a shrink that can do some work > - * comes along it empties the entire cache due to nr >>> > - * freeable. This is bad for sustaining a working set in > - * memory. > - * > - * Hence only allow the shrinker to scan the entire cache when > - * a large delta change is calculated directly. > - */ > - if (delta < freeable / 4) > - total_scan = min(total_scan, freeable / 2); > - > - /* > - * Avoid risking looping forever due to too large nr value: > - * never try to free more than twice the estimate number of > - * freeable entries. > - */ > - if (total_scan > freeable * 2) > - total_scan = freeable * 2; > + total_scan = min(total_scan, (2 * freeable)); > > trace_mm_shrink_slab_start(shrinker, shrinkctl, nr, > freeable, delta, total_scan, priority); > @@ -745,10 +716,15 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, > cond_resched(); > } > > - if (next_deferred >= scanned) > - next_deferred -= scanned; > - else > - next_deferred = 0; > + /* > + * The deferred work is increased by any new work (delta) that wasn't > + * done, decreased by old deferred work that was done now. > + * > + * And it is capped to two times of the freeable items. > + */ > + next_deferred = max_t(long, (nr + delta - scanned), 0); > + next_deferred = min(next_deferred, (2 * freeable)); > + > /* > * move the unused scan count back into the shrinker in a > * manner that handles concurrent updates. > -- > 2.26.2 >