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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 1D245C4332D for ; Wed, 10 Mar 2021 22:42:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0943A64FD3 for ; Wed, 10 Mar 2021 22:42:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233214AbhCJWmD (ORCPT ); Wed, 10 Mar 2021 17:42:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232446AbhCJWlf (ORCPT ); Wed, 10 Mar 2021 17:41:35 -0500 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3D39C061760 for ; Wed, 10 Mar 2021 14:41:12 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id 2so27795675ljr.5 for ; Wed, 10 Mar 2021 14:41:12 -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=2aOtT0quJ6cX5cHdDYWURmJdnr1SZyARqHb+TRhWKsc=; b=Admg/aj1vlbLYpEOJCM2lhdq/aDSricEuYzBabbhb1it9hfceFpiAV/QPXNtTppyq5 qJnLuVOPgsMjRRJvrtooBcJa1ICxA404GQRiGdmTC7VtvIiEEAQ5u2o3Qo3h/bPs5C33 Jr8NW/brQ2b0x6WvgUWz+29Ef6F7s6V+G2Vxul/WxSiuxRMM+wPWYBL1ssttKcscE8sz I2vZwaFCpz7zOPimjCwaRNBNkotBUYJy6r/wbWRH1ToEUWcaT64D3LYLEhPJDDLOEbOH q6dnYsfovRc1OvqghC5s/bwY/KgotFmCfGCuuvAjMWQdAXYTVauVuUfHRlGBA04pydqy MknQ== 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=2aOtT0quJ6cX5cHdDYWURmJdnr1SZyARqHb+TRhWKsc=; b=dmQ6DyTqZiG4LLJmklmrmxLNgRJ/i0lnPg+6CMylpSlnsNL/s4WSwmZPWNnrI5jfvn nmpCT3rl2q0ePsckSqKeJ6txDgXpst3Aa9T9AJlkTIP5cGBlxW+Tq7VURqqfic75f4KA IBUQp++NlUeMWAvMz5lpYmjX+7qSbTgHnb5Uyf3N6aNOUw3vDSgziDjW+asHcr2HEKLH V0getzqVgVmF7u2bPKTMbQeUp6TJjgH8y6/zS1QmqcmcdS54XX+9oIFlUeMZ9y46w9jW kK1c4bvix8E5rQtcPTDCrdJkZSDBelmpYERPfjO5MSURZCKr7EoVbrweuDtbaI+EhFfx AspA== X-Gm-Message-State: AOAM531NGgLJisqcPA0+yHWGjo9OyqsWzGCW7RC/FgnVqzE2ERgfykid F4q8kqrUjXIgefHGGPfXAfUbCbfsAeXOsdJ7ZlrpCA== X-Google-Smtp-Source: ABdhPJzO0krkvJnPAScZsauNzEoSnpIAXNs5veHGggmbR9hLkK41l1MbiXUv0Ytk3FD7vCI/xJhtrgANOKssdCikqlY= X-Received: by 2002:a2e:7d03:: with SMTP id y3mr3158803ljc.0.1615416071164; Wed, 10 Mar 2021 14:41:11 -0800 (PST) MIME-Version: 1.0 References: <20210310174603.5093-1-shy828301@gmail.com> <20210310174603.5093-14-shy828301@gmail.com> In-Reply-To: From: Shakeel Butt Date: Wed, 10 Mar 2021 14:40:59 -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 1:41 PM Yang Shi wrote: > > On Wed, Mar 10, 2021 at 1:08 PM Shakeel Butt wrote: > > > > On Wed, Mar 10, 2021 at 10:54 AM Yang Shi wrote: > > > > > > On Wed, Mar 10, 2021 at 10:24 AM Shakeel Butt wrote: > > > > > > > > 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? > > > > > > Both are covered. > > > > > > > Have you tried just this patch i.e. without the first 12 patches? > > No. It could be applied without the first 12 patches, but I didn't > test this combination specifically since I don't think it would have > any difference from with the first 12 patches. I tested running the > test case under root memcg, it seems equal to w/o the first 12 patches > and the only difference is where to get nr_deferred. I am trying to measure the impact of this patch independently. One point I can think of is the global reclaim. The first 12 patches do not aim to improve the global reclaim but this patch will. I am just wondering what would be negative if any of this patch. 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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 AF2E8C433DB for ; Wed, 10 Mar 2021 22:41:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4DBFD64FC5 for ; Wed, 10 Mar 2021 22:41:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DBFD64FC5 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 DCE3B8D0248; Wed, 10 Mar 2021 17:41:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D7DEF8D0243; Wed, 10 Mar 2021 17:41:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFB688D0248; Wed, 10 Mar 2021 17:41:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id A00E98D0243 for ; Wed, 10 Mar 2021 17:41:13 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6465E6C3E for ; Wed, 10 Mar 2021 22:41:13 +0000 (UTC) X-FDA: 77905436826.05.FBE0147 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf22.hostedemail.com (Postfix) with ESMTP id 983F8C0007CE for ; Wed, 10 Mar 2021 22:41:10 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id m11so27727958lji.10 for ; Wed, 10 Mar 2021 14:41:12 -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=2aOtT0quJ6cX5cHdDYWURmJdnr1SZyARqHb+TRhWKsc=; b=Admg/aj1vlbLYpEOJCM2lhdq/aDSricEuYzBabbhb1it9hfceFpiAV/QPXNtTppyq5 qJnLuVOPgsMjRRJvrtooBcJa1ICxA404GQRiGdmTC7VtvIiEEAQ5u2o3Qo3h/bPs5C33 Jr8NW/brQ2b0x6WvgUWz+29Ef6F7s6V+G2Vxul/WxSiuxRMM+wPWYBL1ssttKcscE8sz I2vZwaFCpz7zOPimjCwaRNBNkotBUYJy6r/wbWRH1ToEUWcaT64D3LYLEhPJDDLOEbOH q6dnYsfovRc1OvqghC5s/bwY/KgotFmCfGCuuvAjMWQdAXYTVauVuUfHRlGBA04pydqy MknQ== 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=2aOtT0quJ6cX5cHdDYWURmJdnr1SZyARqHb+TRhWKsc=; b=o4dO6TmdovW4CnvS+lE2C0gqWfwh4Wsl4bialVNq5UazCp5eSG5IbkHeKwH53mgizJ IOTDviof6Lay5tqmtajErtT05myjGGCuq2UdOxSKxrmMZy4ZukrIH7q+chz2bM2nKFG9 xbCOumKymcD3mLu/viOgf+8xLoTv878G8gRcCkpWwcATATLF4ldKFT9YJ1O2PccxMkFq lnf0Xbpo8hqD26C/bARZTSDmDBXumky12vHd/1HOh2Ufv202BUlpVz5zZQz8IoQIQW5y IjS+QQivmFjdXnwztq9qCvPjpU3m+2baXr+PeS7awpvE0FyNOj3dol4F17i92csYUD1w Lcug== X-Gm-Message-State: AOAM530i/SCSbDsBaCA+OKPMSDw53yukcilCCSQZYqhzAtlmV2/kR/Ja ROKEHm3Oz+U0+7bXh/1ggDeCy9Ozw+M1YKVLZ1CF2w== X-Google-Smtp-Source: ABdhPJzO0krkvJnPAScZsauNzEoSnpIAXNs5veHGggmbR9hLkK41l1MbiXUv0Ytk3FD7vCI/xJhtrgANOKssdCikqlY= X-Received: by 2002:a2e:7d03:: with SMTP id y3mr3158803ljc.0.1615416071164; Wed, 10 Mar 2021 14:41:11 -0800 (PST) MIME-Version: 1.0 References: <20210310174603.5093-1-shy828301@gmail.com> <20210310174603.5093-14-shy828301@gmail.com> In-Reply-To: From: Shakeel Butt Date: Wed, 10 Mar 2021 14:40:59 -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: 983F8C0007CE X-Stat-Signature: e18bgwu6u1y6dr9xn13y16d5dza4iyoo 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: 1615416070-412345 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 1:41 PM Yang Shi wrote: > > On Wed, Mar 10, 2021 at 1:08 PM Shakeel Butt wrote: > > > > On Wed, Mar 10, 2021 at 10:54 AM Yang Shi wrote: > > > > > > On Wed, Mar 10, 2021 at 10:24 AM Shakeel Butt wrote: > > > > > > > > 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? > > > > > > Both are covered. > > > > > > > Have you tried just this patch i.e. without the first 12 patches? > > No. It could be applied without the first 12 patches, but I didn't > test this combination specifically since I don't think it would have > any difference from with the first 12 patches. I tested running the > test case under root memcg, it seems equal to w/o the first 12 patches > and the only difference is where to get nr_deferred. I am trying to measure the impact of this patch independently. One point I can think of is the global reclaim. The first 12 patches do not aim to improve the global reclaim but this patch will. I am just wondering what would be negative if any of this patch.