Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp925134pxb; Tue, 9 Feb 2021 16:54:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJywBKr226zmyH+ES77om1zNnB3VnwF7oHQ/lHCpMB0QYyyXWPKxEySNCd6pKEh7/psw+Nat X-Received: by 2002:a17:906:ecb6:: with SMTP id qh22mr416128ejb.252.1612918480223; Tue, 09 Feb 2021 16:54:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612918480; cv=none; d=google.com; s=arc-20160816; b=BSw20gB5tCeb4SlkkyKp2zIitcUpi821Pn6Z+yOMhECaBU5ILb6gM479bxNGZmGZ4n igeZGuhd5sD4VTYUUT+v2GNOyHqezvkOBx4aPm8BuODDk2nkeNMXAS7BvpYEMaRW1tuu nVAmh3MRY85tL2FMXtfca5ySBeBESy+bXr4/dvIJyZD6WddMP1uJcTp7eyEdZNjDnSSI s39J7Y/X8N2/cdBjQzlAO1wdnXSv1M/zgAmdd74T7VxD+iOhAxd5R5cVZ8kdeV8rA1e3 P/gbYR4xTtGDkwitV4CuxBPN9BafPIqufnF3AJnbNXYxVZKQ0j+//14hEQoh3HmAyVlf p3cg== 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=YMDK4UroH5MqOsAhIDFwbI5nMOuGZdD6WdCbLAFzleYLtK4qiWFmK8d+JrMjZknITT sBohR6SgbB+7M3nuzGw5Exhom4S/VHH1PYCh/f2jKbU/Yp/7dSwy5x2tPk+6tqvYpm6s aDHx31bdtGe21vT4nuHdpewpEidp2Y7mXffbk/svHqMYkBWtZie3CHh+nogl8kSMV3/z fnc20sQteO1gA5+FYUQS/GwcGZl0aw6XNr14RHm5NwpDVo0DkwDOaIRywfwI0D+RrtEz kA4InnUhfTulF/B3uzAT01QbbVaANluZbqHUE0FebPkuPAfsZni2k12fHeNSx02hylpW LcDg== 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 h15si200332ejd.725.2021.02.09.16.54.17; Tue, 09 Feb 2021 16:54:40 -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 S234162AbhBJAxS (ORCPT + 99 others); Tue, 9 Feb 2021 19:53:18 -0500 Received: from mga12.intel.com ([192.55.52.136]:10379 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233872AbhBIWJC (ORCPT ); Tue, 9 Feb 2021 17:09:02 -0500 IronPort-SDR: MldrIrg3w5REvajKrIdpaITKdmkufNyApVrID8u1Z01K9GSP6RoUgjTYRj/fYzCvExQqdpj/lT ZDdG//SF87Iw== X-IronPort-AV: E=McAfee;i="6000,8403,9890"; a="161113148" X-IronPort-AV: E=Sophos;i="5.81,166,1610438400"; d="scan'208";a="161113148" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2021 13:30:35 -0800 IronPort-SDR: 0NuyfNv3/5PMZnwwx7T68ohTVg5P571Vdttta2Ey1bZPdT00ExB3kdjlJBHEt+OpZP7kvgRGmH NYF2ky9Gr9Wg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,166,1610438400"; d="scan'208";a="361953027" Received: from skl-02.jf.intel.com ([10.54.74.28]) by orsmga006.jf.intel.com with ESMTP; 09 Feb 2021 13:30:35 -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 2/3] mm: Force update of mem cgroup soft limit tree on usage excess Date: Tue, 9 Feb 2021 12:29:46 -0800 Message-Id: <90ef1dbc8ba6112794a3d09ecfed73f385f08eb7.1612902157.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