From patchwork Wed Jan 27 23:33:45 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Shi X-Patchwork-Id: 12051229 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=-13.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 37963C433E6 for ; Wed, 27 Jan 2021 23:34:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E91FE64D7F for ; Wed, 27 Jan 2021 23:34:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E91FE64D7F 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 D57286B007D; Wed, 27 Jan 2021 18:34:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C8C7B6B007E; Wed, 27 Jan 2021 18:34:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2CFB6B0081; Wed, 27 Jan 2021 18:34:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0246.hostedemail.com [216.40.44.246]) by kanga.kvack.org (Postfix) with ESMTP id 94D266B007D for ; Wed, 27 Jan 2021 18:34:17 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 515EB8249980 for ; Wed, 27 Jan 2021 23:34:17 +0000 (UTC) X-FDA: 77753160954.27.ocean16_5a087032759b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 368B63D663 for ; Wed, 27 Jan 2021 23:34:17 +0000 (UTC) X-HE-Tag: ocean16_5a087032759b X-Filterd-Recvd-Size: 6036 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 Jan 2021 23:34:16 +0000 (UTC) Received: by mail-pg1-f178.google.com with SMTP id g15so2809647pgu.9 for ; Wed, 27 Jan 2021 15:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=6zTr7oQng8A44UhAdRsCMp9TEBoUovtHbqgUeR1gt90=; b=ufz7fAq+D1Ldzv3KQIQSXZJiFZzJBw07ab2lzgQc/xuHOlmS+AJXgqzLu0ip18ohT8 JaE7UH03ZVgMWDLZUo4zt+NJLC0MyzS9x/iCNVun2KLczlFHn6KUEs1ISJyWcpLqsO+5 Uubhk+CWE8XQ5f94DHoDndqULxC30pSdqwurFm4eUs6pyEdBULbSA8b4iJ+xtBQ7g9Vz +eEortvkZ9BZVCes8RtcDa9eM3QutksUtdWBOxxts+d19fAF/iQ70rykYqSSRub/FI1k z9mTe2t8ETz37O5vFOsRcf9RGnwUhXRFFTjzn/3VQ7XMlisXynda4Kpf9UL8+5jfSViK KLQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=6zTr7oQng8A44UhAdRsCMp9TEBoUovtHbqgUeR1gt90=; b=Lgn5nruxUwkFUw8lymXUO/czn4OYuaoLny1/zS/gx/MTiHxlI7vE62HQWKjs8RIqKX xulYSKclULx7Zw616JMaErncWqc0P0kh8M5rg1zrW2VQykp29xMSzTCSMqQgTKVzsKg0 BK7NzWwqbr31P/8FN3ouZs/8MkM+qweWqEu6qEIIZcephi0oSyN5qtRp2J8MyTD00qD9 u2GZNlxw3w6SwJplESywAUayvbGJze1UqPjCjRii3rRT8j97N0p+ge4YLu2Tcul5t13Q P19CgkfXgGkFIfPNU5svIRFJx2MsgpoPVWroaGjA2nzNpgPcuJFU8qUKs/PRX9mHJ42V SDYA== X-Gm-Message-State: AOAM530qCxxWqT5cqDHIggxxAade9q6XpnTtawyS2KaTVVG+hwSjEzxk 5mJWwOnAMnGC9QYoRAn2WSk= X-Google-Smtp-Source: ABdhPJxRoYG80XjL2szA2Xx9L3qJm5uTvO6Za+n3fNgIluivnAlS4ESMxzMdazerK1m7Lg4dmWhFyg== X-Received: by 2002:a63:da46:: with SMTP id l6mr14006921pgj.134.1611790455956; Wed, 27 Jan 2021 15:34:15 -0800 (PST) Received: from localhost.localdomain (c-73-93-239-127.hsd1.ca.comcast.net. [73.93.239.127]) by smtp.gmail.com with ESMTPSA id 124sm3498648pfd.59.2021.01.27.15.34.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jan 2021 15:34:15 -0800 (PST) From: Yang Shi To: guro@fb.com, ktkhai@virtuozzo.com, shakeelb@google.com, david@fromorbit.com, hannes@cmpxchg.org, mhocko@suse.com, akpm@linux-foundation.org Cc: shy828301@gmail.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [v5 PATCH 11/11] mm: vmscan: shrink deferred objects proportional to priority Date: Wed, 27 Jan 2021 15:33:45 -0800 Message-Id: <20210127233345.339910-12-shy828301@gmail.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20210127233345.339910-1-shy828301@gmail.com> References: <20210127233345.339910-1-shy828301@gmail.com> MIME-Version: 1.0 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: 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, no regression is spotted so far. But it still may have regression for some corner cases. Signed-off-by: Yang Shi --- mm/vmscan.c | 40 +++++----------------------------------- 1 file changed, 5 insertions(+), 35 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 55ad91a26ba3..471d037d735e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -662,7 +662,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; @@ -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,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.