Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6795556pxb; Wed, 17 Feb 2021 13:46:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJx2obaIAp5bT2s+j+KodSMrlLp+oXaT++3TRf+TDWmRs1TyAx1C6ipLIiwDbYK8yuUC+a0a X-Received: by 2002:a05:6402:1155:: with SMTP id g21mr800028edw.279.1613598388221; Wed, 17 Feb 2021 13:46:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613598388; cv=none; d=google.com; s=arc-20160816; b=UhLgJD3E4cbhuN1C41pis6WL8V0DhMoEq8dT/KeEKGF8dRn8gcRTuTXbbWrC6tD3zc Yl9A99kSeqAzUCi+5uwGDaHD8W0QCeZKOrndYMI3nIzInSOiKSGDuXV+rpeF+QJMII0G 3e+ljnVEtXPHyIw7+0RqTdHUa9rZiEHzIpg2BUoVLP5AhOYyZh+e7GTH9ChosTbumpKS bPJthkc1RJP0SP9/G1lT7kGzl83cvg2nCeyTUaPUe8XBZqKA4d61WeXs30yu+9YIoHdP 9yej5s68SBIUCFUBfHCOxeoIdlpCHMq3kL+XpZh+RHJWeLjC4krV3Yn+IicUsnOUgFWu RSgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :ironport-sdr:ironport-sdr; bh=g+ZzLkR8JwZl6Z3XuS9cteOshoI9im4JNH1Oqn+0m1E=; b=rnfK54Fu4cLuPXKgvsB2G9JA9r1L57Yaq5mbWCFIFZZ+Xef54Uslwb+0a6TtUVX4pF ZJ6UK/NdonzXVsNIN/LN8OKcNGXxF/hEB+XKbIkqoVcWjT4SOWYeaFcGHlOgn9+Vtyqj EYSj3Rwe1WG1h8ppq66AitCw7sGCmhrBAiVHA2zRvXIaSCrBrOgsbY7lEeSVNQ9ZWZDk K4jeo38ul9yolMy7P8U5ozDgUBQVCFoNsYtgOcjzLirbnlwDsezH1BvoHevYrS6QMIVA 4Mgx5Eyg2qieZoE32JWCdSGSDRdUqxT61DHqNvbesdigbzM3Pw//543dxDx2BDIcvyPE zrfA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hp19si2353221ejc.733.2021.02.17.13.45.58; Wed, 17 Feb 2021 13:46:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232729AbhBQVnt (ORCPT + 99 others); Wed, 17 Feb 2021 16:43:49 -0500 Received: from mga14.intel.com ([192.55.52.115]:37251 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232478AbhBQVnm (ORCPT ); Wed, 17 Feb 2021 16:43:42 -0500 IronPort-SDR: CSxJqeqQoDuQ+cH/498vjRF8ceZrUNQnrBREoeXm1CjS2F+2++r1tIZisNWCQv1UXGVq9K7tAT 5MZmx3URE1xg== X-IronPort-AV: E=McAfee;i="6000,8403,9898"; a="182538757" X-IronPort-AV: E=Sophos;i="5.81,185,1610438400"; d="scan'208";a="182538757" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 13:41:55 -0800 IronPort-SDR: 9Hq9KtM7miCiBDav7pvUqi5nyuDRGHZpaD7BBiidOVHP9uYoSc5++KYkN6vXYDuFE8r3evNcC+ tofPWpXB6Xqw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,185,1610438400"; d="scan'208";a="401430712" Received: from skl-02.jf.intel.com ([10.54.74.28]) by orsmga007.jf.intel.com with ESMTP; 17 Feb 2021 13:41:55 -0800 From: Tim Chen To: Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov Cc: Tim Chen , Dave Hansen , Ying Huang , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/3] mm: Force update of mem cgroup soft limit tree on usage excess Date: Wed, 17 Feb 2021 12:41:35 -0800 Message-Id: <06f1f92f1f7d4e57c4e20c97f435252c16c60a27.1613584277.git.tim.c.chen@linux.intel.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org To rate limit updates to the mem cgroup soft limit tree, we only perform updates every SOFTLIMIT_EVENTS_TARGET (defined as 1024) memory events. However, this sampling based updates may miss a critical update: i.e. when the mem cgroup first exceeded its limit but it was not on the soft limit tree. It should be on the tree at that point so it could be subjected to soft limit page reclaim. If the mem cgroup had few memory events compared with other mem cgroups, we may not update it and place in on the mem cgroup soft limit tree for many memory events. And this mem cgroup excess usage could creep up and the mem cgroup could be hidden from the soft limit page reclaim for a long time. Fix this issue by forcing an update to the mem cgroup soft limit tree if a mem cgroup has exceeded its memory soft limit but it is not on the mem cgroup soft limit tree. Reviewed-by: Ying Huang Signed-off-by: Tim Chen --- mm/memcontrol.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index a51bf90732cb..d72449eeb85a 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -985,15 +985,22 @@ static bool mem_cgroup_event_ratelimit(struct mem_cgroup *memcg, */ static void memcg_check_events(struct mem_cgroup *memcg, struct page *page) { + struct mem_cgroup_per_node *mz; + bool force_update = false; + + mz = mem_cgroup_nodeinfo(memcg, page_to_nid(page)); + if (mz && !mz->on_tree && soft_limit_excess(mz->memcg) > 0) + force_update = true; + /* threshold event is triggered in finer grain than soft limit */ - if (unlikely(mem_cgroup_event_ratelimit(memcg, + if (unlikely((force_update) || mem_cgroup_event_ratelimit(memcg, MEM_CGROUP_TARGET_THRESH))) { bool do_softlimit; do_softlimit = mem_cgroup_event_ratelimit(memcg, MEM_CGROUP_TARGET_SOFTLIMIT); mem_cgroup_threshold(memcg); - if (unlikely(do_softlimit)) + if (unlikely((force_update) || do_softlimit)) mem_cgroup_update_tree(memcg, page); } } -- 2.20.1