From patchwork Wed Jun 26 21:18:27 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jesper Dangaard Brouer X-Patchwork-Id: 13713435 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E78AC27C4F for ; Wed, 26 Jun 2024 21:18:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5A036B0096; Wed, 26 Jun 2024 17:18:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE24F6B0098; Wed, 26 Jun 2024 17:18:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5BC06B0099; Wed, 26 Jun 2024 17:18:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7EC6C6B0096 for ; Wed, 26 Jun 2024 17:18:36 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id ACDEA41769 for ; Wed, 26 Jun 2024 21:18:35 +0000 (UTC) X-FDA: 82274303790.27.7E759D4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id EF4731C000C for ; Wed, 26 Jun 2024 21:18:33 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="U6ieFS/G"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of hawk@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=hawk@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719436695; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NZBvqTBsRJ02yoXGdvbuZ65Eq7k3HG8dnkudVAhfP6A=; b=nu/8Edb7QgdfeHVrsJk/ERDXaDZ+qhqNT4aqH6zp6Lwd96Fp5hmRyeBVxcUyB01kSY88d4 M7uxRnw7aHqur6ZFKIH4iSNRXJK847rtu+6okmrQ3xNPs2k4AwfcMMnvXhMxg/yPCY+Swi 39/LSxjKqCbA5nQ58QdfyqE3pTrS5hA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719436695; a=rsa-sha256; cv=none; b=xk1fJEvlChzf6s8Qcy89/u0x/SDoYqFW0hOpaSsLgcM3pENCicSTAU7j8mbFeaTSiUV8tr hkxKcNsvfHee6xFprMAHHe3iGtGBEfDPtsadLVBXTbgnDV6gzQo3AnpObqwjYcAYhvONt1 Hve2cC7qZae/OSVPSnz2BnFK0qspHC0= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="U6ieFS/G"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of hawk@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=hawk@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E9EF1613E2; Wed, 26 Jun 2024 21:18:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14138C116B1; Wed, 26 Jun 2024 21:18:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719436712; bh=Fte+YSeQ6XczvTdXOJBvpZBjnXsFCrrzsvBXG8KQyNs=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=U6ieFS/Gcvr/Hq+fX5/rvTxKhR3jGqMx0im4R27mH/nGauoRKT5VTGnP7y5HVDzup +bUJ8hqgjtZjY/LZMEJp0jkB8XzNG5R6CAfS+q3b6wemm+2yeUuIqMIxzIuOK938D5 dCGLA+5hAmyoFTfS2jZlbpmr+YbSagD4g97N3TSOZbtB1B7bdNtKdK+H9GFj2RiSnm 2N9patZYlTspjkhwtJjoFdUHn5mW8Fk4amKFkpU4At9vZJLmW206/lxzwrl3REFDyd XhKmRbX0quGF2pGiU2wxcl9lfok6v/GC479XV7oUHYvmQTq5h1OVnuCcyqKvvzpbKo 5RxRJnJPSOEKg== Subject: [PATCH V3 2/2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes From: Jesper Dangaard Brouer To: tj@kernel.org, cgroups@vger.kernel.org, yosryahmed@google.com, shakeel.butt@linux.dev Cc: Jesper Dangaard Brouer , hannes@cmpxchg.org, lizefan.x@bytedance.com, longman@redhat.com, kernel-team@cloudflare.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Wed, 26 Jun 2024 23:18:27 +0200 Message-ID: <171943668946.1638606.1320095353103578332.stgit@firesoul> In-Reply-To: <171943667611.1638606.4158229160024621051.stgit@firesoul> References: <171943667611.1638606.4158229160024621051.stgit@firesoul> User-Agent: StGit/1.5 MIME-Version: 1.0 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: EF4731C000C X-Stat-Signature: 5fwfdis5toy8cemhc6oxhaqb7fkc8seo X-Rspam-User: X-HE-Tag: 1719436713-493781 X-HE-Meta: U2FsdGVkX18gbzxQQ2Mhmx4AvsWFiGSrXHFzBFKOvpEVAWV1uZxNZn2WbkHz2s//4tArK2Sap5iJC1lfCuYOYZlTu5Vsv/MirGrHc5MTaP7E77xJLwlCACLIJ0AOGdNepELS7W6vHUgFu4a3U8P0LNNy9VFlsWObwkGwYiSdfaSan3u9k/GkJDkOtz3WJfci+w+hJxbT1xtcgUxhdvdb2HpmnWtMCRGCTeuoDqvVGag+Ths8LhHH5eSCiNeFdIpvvu+eo9rU5INWo36ypRFGk3TRe45oLhlf2g47+yK4k8qjJ7xYLmcUPzkV+g+cpvmELYLsr24N0FN6tQH9yxzo2qfO4H22JRw88DFPZKoIAIBkL3fzzbMZG9WEouLBGikjxUd3OrNjsENARucH+7jyjuok5a0/ok/vBCZfGSixPxJgK3cXfEgOTbot/kDIrFTsaG0AG7akgBLJs3TsLnFf+Dtx2TC//z3ZZMGEqqEGP61ntq4Ue8s7ch8afQ7oy2R/jJ5YPMyRjjmwT8HUTiivaezHGlOBK5zyoIRqa3ENp6NKf0C1MvGaP3s2MZk8To19xBg4ydQx7ZNYA6ejpA+bFyG1e8cjlqcKiZ6O3ymAyVVhv6FCouBLVSZscswCYf7OMz3PBAWUa9DjfP5qrtZUcpMMRlZnPVaiMSiz9VhZzW9QIyLLEB0SVqvyccBD4zJGD4y+/Gq5Z4dc9AUBPmzqOVH/zG/PpguMhdKBNITJlc60zUGYpF2+pftl6DpKB5y7XZBgwDT5S6ShSi9hHBH8XodNxvUZJdjTiUDCrGlxIGZbzHBvDGtQu/rOwZD/1puuN0yvs+7sSYHIRNFcOIYjraQOUPbCDD+KQOftqm0+W2QUTf0jQN+sA/fuzPmzG4Z+C+sWt8CoyPhop2AMvj7Q4A+3iPo7VzjiaVKz+e2m7gJCc2mLGx9JFmfT0gZtgX+DqV8hOYGIe5Gr3Z+WhsT w7tlJNAr qh2YyoijE13qtmEDJNetPQw9Aa91HR5K+XymULr4W5VWzhhts1NoQPwL8zBsMcIc/RB5KguLbxgu+vnrx3HIrz7Jhs8bOYGYJvaj3+TAU8DEC87uohtoyODTAsL4jP6CoEB1ML89toA+ijdecarJ+6U9aQlE6fj0sqWXnQRfdlZ1F3/IYFS97TQCS+5RrOvjgY5Tk47yXZ/hQXnn5lQdpD/Nxq2b61NpGORpAXD6X/q9prhBucX1IYT/n41Cx11M6huYHK6qc8PHppGe7YSXTfVmK3Bqa5tAOuDTp X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Avoid lock contention on the global cgroup rstat lock caused by kswapd starting on all NUMA nodes simultaneously. At Cloudflare, we observed massive issues due to kswapd and the specific mem_cgroup_flush_stats() call inlined in shrink_node, which takes the rstat lock. On our 12 NUMA node machines, each with a kswapd kthread per NUMA node, we noted severe lock contention on the rstat lock. This contention causes 12 CPUs to waste cycles spinning every time kswapd runs. Fleet-wide stats (/proc/N/schedstat) for kthreads revealed that we are burning an average of 20,000 CPU cores fleet-wide on kswapd, primarily due to spinning on the rstat lock. To help reviewer follow code: When the Per-CPU-Pages (PCP) freelist is empty, __alloc_pages_slowpath calls wake_all_kswapds(), causing all kswapdN threads to wake up simultaneously. The kswapd thread invokes shrink_node (via balance_pgdat) triggering the cgroup rstat flush operation as part of its work. This results in kernel self-induced rstat lock contention by waking up all kswapd threads simultaneously. Leveraging this detail: balance_pgdat() have NULL value in target_mem_cgroup, this cause mem_cgroup_flush_stats() to do flush with root_mem_cgroup. To avoid this kind of thundering herd problem, kernel previously had a "stats_flush_ongoing" concept, but this was removed as part of commit 7d7ef0a4686a ("mm: memcg: restore subtree stats flushing"). This patch reintroduce and generalized the concept to apply to all users of cgroup rstat, not just memcg. If there is an ongoing rstat flush, and current cgroup is a descendant, then it is unnecessary to do the flush. For callers to still see updated stats, wait for ongoing flusher to complete before returning, but add timeout as stats are already inaccurate given updaters keeps running. Fixes: 7d7ef0a4686a ("mm: memcg: restore subtree stats flushing"). Signed-off-by: Jesper Dangaard Brouer --- V2: https://lore.kernel.org/all/171923011608.1500238.3591002573732683639.stgit@firesoul/ V1: https://lore.kernel.org/all/171898037079.1222367.13467317484793748519.stgit@firesoul/ RFC: https://lore.kernel.org/all/171895533185.1084853.3033751561302228252.stgit@firesoul/ kernel/cgroup/rstat.c | 61 ++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 50 insertions(+), 11 deletions(-) diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c index 2a42be3a9bb3..f21e6b1109a4 100644 --- a/kernel/cgroup/rstat.c +++ b/kernel/cgroup/rstat.c @@ -2,6 +2,7 @@ #include "cgroup-internal.h" #include +#include #include #include @@ -11,6 +12,8 @@ static DEFINE_SPINLOCK(cgroup_rstat_lock); static DEFINE_PER_CPU(raw_spinlock_t, cgroup_rstat_cpu_lock); +static struct cgroup *cgrp_rstat_ongoing_flusher; +static DECLARE_COMPLETION(cgrp_rstat_flusher_done); static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu); @@ -346,6 +349,44 @@ static void cgroup_rstat_flush_locked(struct cgroup *cgrp) } } +#define MAX_WAIT msecs_to_jiffies(100) +/* Trylock helper that also checks for on ongoing flusher */ +static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp) +{ +retry: + bool locked = __cgroup_rstat_trylock(cgrp, -1); + if (!locked) { + struct cgroup *cgrp_ongoing; + + /* Lock is contended, lets check if ongoing flusher is already + * taking care of this, if we are a descendant. + */ + cgrp_ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher); + if (!cgrp_ongoing) + goto retry; + + if (cgroup_is_descendant(cgrp, cgrp_ongoing)) { + wait_for_completion_interruptible_timeout( + &cgrp_rstat_flusher_done, MAX_WAIT); + + return false; + } + __cgroup_rstat_lock(cgrp, -1, false); + } + /* Obtained lock, record this cgrp as the ongoing flusher */ + reinit_completion(&cgrp_rstat_flusher_done); + WRITE_ONCE(cgrp_rstat_ongoing_flusher, cgrp); + + return true; /* locked */ +} + +static void cgroup_rstat_unlock_flusher(struct cgroup *cgrp) +{ + WRITE_ONCE(cgrp_rstat_ongoing_flusher, NULL); + complete_all(&cgrp_rstat_flusher_done); + __cgroup_rstat_unlock(cgrp, -1); +} + /** * cgroup_rstat_flush - flush stats in @cgrp's subtree * @cgrp: target cgroup @@ -361,18 +402,13 @@ static void cgroup_rstat_flush_locked(struct cgroup *cgrp) */ __bpf_kfunc void cgroup_rstat_flush(struct cgroup *cgrp) { - bool locked; - might_sleep(); - locked = __cgroup_rstat_trylock(cgrp, -1); - if (!locked) { - /* Opportunity to ongoing flush detection */ - __cgroup_rstat_lock(cgrp, -1, false); - } + if (!cgroup_rstat_trylock_flusher(cgrp)) + return; cgroup_rstat_flush_locked(cgrp); - __cgroup_rstat_unlock(cgrp, -1); + cgroup_rstat_unlock_flusher(cgrp); } /** @@ -388,8 +424,11 @@ void cgroup_rstat_flush_hold(struct cgroup *cgrp) __acquires(&cgroup_rstat_lock) { might_sleep(); - __cgroup_rstat_lock(cgrp, -1, true); - cgroup_rstat_flush_locked(cgrp); + + if (cgroup_rstat_trylock_flusher(cgrp)) + cgroup_rstat_flush_locked(cgrp); + else + __cgroup_rstat_lock(cgrp, -1, true); } /** @@ -399,7 +438,7 @@ void cgroup_rstat_flush_hold(struct cgroup *cgrp) void cgroup_rstat_flush_release(struct cgroup *cgrp) __releases(&cgroup_rstat_lock) { - __cgroup_rstat_unlock(cgrp, -1); + cgroup_rstat_unlock_flusher(cgrp); } int cgroup_rstat_init(struct cgroup *cgrp)