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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 2779CC433DB for ; Thu, 4 Feb 2021 17:29:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6C8864E02 for ; Thu, 4 Feb 2021 17:29:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6C8864E02 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1CB846B0005; Thu, 4 Feb 2021 12:29:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17D0F6B0006; Thu, 4 Feb 2021 12:29:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 094B36B0070; Thu, 4 Feb 2021 12:29:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id E3DFC6B0005 for ; Thu, 4 Feb 2021 12:29:22 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AA445181AEF1A for ; Thu, 4 Feb 2021 17:29:22 +0000 (UTC) X-FDA: 77781271764.07.art75_310c40f275dd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 835091803F9A3 for ; Thu, 4 Feb 2021 17:29:22 +0000 (UTC) X-HE-Tag: art75_310c40f275dd X-Filterd-Recvd-Size: 7259 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Feb 2021 17:29:21 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id q12so5661935lfo.12 for ; Thu, 04 Feb 2021 09:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X1ahJvFsrZks1Lk0ripDXnB6weXUyAGbfZ45blD5PTU=; b=RSpK0Teg2yPbyx+tN32lHdP56HoEVGFGksT+JkghM2BilhAM++ndPSiHehfezfx0vv 2usPaDOoocqRjyGUkmvCzcEjiTOnJ2PIaLjJOc5JFg5xEG5bXNPJN0F0VhbqgEjH47jN p4Dk8zw7m3i1JeiIVok9xhDnXN5EfMus1K9zEGqO1LCYAF1uYpHYDTl+HaMoKtVH4rVa 5I3b+VYivjxIgN7ELRhDJjjgz6Tfosbc/n7fZ6IeoDnX+lFZ0AYzwojGYqztUBUc33c2 Wi/aYf0LBhH1zzgtE7od4YXuk3tNwtoeK3gDzNkKvZs5U/GFOTgTWZFsccOJVHz+HqgM nF9w== 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=X1ahJvFsrZks1Lk0ripDXnB6weXUyAGbfZ45blD5PTU=; b=VLEQE29YkCL5QfUFbzegQR3lDS1x6o868pSZ4EutFnabOCBhxlRWXO+rCmlXwSV88q +5G7J972uCDfzxGKC8v09DOppA1h/rL9DnV5W0YRwptW6DApgwAQoEv1TjwiNFo6q2yK wVHu8A4XXESLt69UUptikKIrjEttL8/HFlrq0NPpZFNzlP4KFTMhT/NT2FzpoGZvrKVa 7cKOEzvCiy/sx1w09rj5YV7tdYEoHFM0JguBsAgom8cxrmdEro03zQrjVM6Hf9O0iWfr XVwT2noXtLGSDg5tJXDyvkMEq4xMxApmdPVlal33Xw0dh9joPSu4xUBrNmGLfkk7Qmex dDBQ== X-Gm-Message-State: AOAM531UdU4UODyQBZ0Gv7M69/hY0tgvEvVpUZX7ccQruL+aRIwt39nE kSEb1E/3A9c/UxSz8nLoaDkekRZ+JSyXAxI4e3w= X-Google-Smtp-Source: ABdhPJwT/uirdmDDpof36RQ4WHOo7qc+S6n5DG40Du1EdYVt6nWCd+lES33v9igd/hfr1ZQ/k/YbFx5uatDCgLJ9eOA= X-Received: by 2002:a19:23c5:: with SMTP id j188mr265462lfj.430.1612459759029; Thu, 04 Feb 2021 09:29:19 -0800 (PST) MIME-Version: 1.0 References: <20210203172042.800474-1-shy828301@gmail.com> <20210203172042.800474-12-shy828301@gmail.com> <8c11f94a-bd1a-3311-2160-0f2c83994a53@virtuozzo.com> In-Reply-To: <8c11f94a-bd1a-3311-2160-0f2c83994a53@virtuozzo.com> From: Yang Shi Date: Thu, 4 Feb 2021 09:29:06 -0800 Message-ID: Subject: Re: [v6 PATCH 11/11] mm: vmscan: shrink deferred objects proportional to priority To: Kirill Tkhai Cc: Roman Gushchin , Vlastimil Babka , Shakeel Butt , Dave Chinner , Johannes Weiner , Michal Hocko , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" 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 Thu, Feb 4, 2021 at 2:23 AM Kirill Tkhai wrote: > > On 03.02.2021 20:20, 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 fron 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. > > > > Signed-off-by: Yang Shi > > For some time I was away from this do_shrink_slab() magic formulas and recent changes, > so I hope somebody else, who is being in touch with this, can review. Yes, I agree it is intimidating. The patch has been tested in our test and production environment for a couple of months, so far no regression is spotted. Of course it doesn't mean it will not incur regression for other workloads. My plan is to leave it stay in -mm then linux-next for a while for a broader test. The first 10 patches could go to Linus's tree separately. > > > --- > > mm/vmscan.c | 40 +++++----------------------------------- > > 1 file changed, 5 insertions(+), 35 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 574d920c4cab..d0a86170854b 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -649,7 +649,6 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, > > */ > > nr = count_nr_deferred(shrinker, shrinkctl); > > > > - total_scan = nr; > > if (shrinker->seeks) { > > delta = freeable >> priority; > > delta *= 4; > > @@ -663,37 +662,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); > > @@ -732,10 +703,9 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, > > cond_resched(); > > } > > > > - if (next_deferred >= scanned) > > - next_deferred -= scanned; > > - else > > - next_deferred = 0; > > + next_deferred = max_t(long, (nr - scanned), 0) + total_scan; > > + next_deferred = min(next_deferred, (2 * freeable)); > > + > > /* > > * move the unused scan count back into the shrinker in a > > * manner that handles concurrent updates. > > Thanks > >