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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B89BC3DA42 for ; Wed, 10 Jul 2024 12:25:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A78036B0088; Wed, 10 Jul 2024 08:25:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A27EC6B0089; Wed, 10 Jul 2024 08:25:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F0046B008A; Wed, 10 Jul 2024 08:25:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 70BD26B0088 for ; Wed, 10 Jul 2024 08:25:00 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EAF9D1A06EC for ; Wed, 10 Jul 2024 12:24:59 +0000 (UTC) X-FDA: 82323762318.07.F6E0DF8 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf17.hostedemail.com (Postfix) with ESMTP id 8568140018 for ; Wed, 10 Jul 2024 12:24:57 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=F6yyd6Dr; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of hawk@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=hawk@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720614272; a=rsa-sha256; cv=none; b=W7KLknZK7qSHG7Y4ucJRhG4mhDHrhWimApAORUkp87W2fyWaXDMfXpZ9g9OH4zBoHdqGpe 9tGZvJXk4vOAR8e089ZH6wSgS1HR2Xxw7Ew556hb999ybDmN6Y4oYE2X54HkK0hXjbDiXa nogikZ5jC4Y5NTWQfeds5/L/gYlTiB4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=F6yyd6Dr; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of hawk@kernel.org designates 145.40.73.55 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=1720614272; 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=WpGgzhrUgrpRoLeyauFt9+VbHDsMP15YKEOdy43yWtY=; b=qfqnqaRv/DNhUicZtMdiHUGxQvwEpGHEh+EPdgFRFkcWXWRA7D0RY5tl3tybfPMdNDPsmO PSTozifyQy+372bLbbeRVFq6sMo5s75T3X9GASWQjraRbECQewUfOjF14/xPs00vMaajb7 aVzJ06u7hTS18TdZelbJRu41DPwMuqU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 00B3CCE0F0E; Wed, 10 Jul 2024 12:24:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57FEAC32781; Wed, 10 Jul 2024 12:24:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720614292; bh=Z1iHW0xwjuUolgLlUVZ38XpPOyQpCRbkMMbxly+aDN0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=F6yyd6Dr3eH/h9NOEcsOXE6RR+cYQo7q/p6k/uVgKwfpQFUiUqSRej7p9cQYDyEBm 5x2AGTV6CNyHRFFr1tTnYRKbvNreLNXXQQ6iOPQI1NzZOBYCJ/ufKeGyY/c63raVRh wNouwbRtyeZugTFv8HGaRhQ+QLbEj1+mSxg3N0NQaSdgPnXukkgf3oODtpRNcznT91 hGCgzQQXC5JAGma2bWHmsFtcaXEN+HFDNbIvVtUy70wbd7U6vbb2lezmWfTPP2rm01 GubsmqSvmmF66LkP4RW3KiBY9DbmyTnGVKy+Ioug1+t+MSwPNRyuE8UmeNG42d3xOf QqA2I6oFIqQsg== Message-ID: <22d972e9-4abd-4990-9fc6-828f3300b34b@kernel.org> Date: Wed, 10 Jul 2024 14:24:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V6] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes To: Shakeel Butt Cc: tj@kernel.org, cgroups@vger.kernel.org, yosryahmed@google.com, hannes@cmpxchg.org, lizefan.x@bytedance.com, longman@redhat.com, kernel-team@cloudflare.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <172052399087.2357901.4955042377343593447.stgit@firesoul> <3oyf3p3xyhxxugucwsuhtuais6547rvzob5fkz3yc7jgocow2n@odqb6l2oweto> Content-Language: en-US From: Jesper Dangaard Brouer In-Reply-To: <3oyf3p3xyhxxugucwsuhtuais6547rvzob5fkz3yc7jgocow2n@odqb6l2oweto> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8568140018 X-Stat-Signature: ut77jcdzmuwdxz1ekhxyh9nsfbdhh485 X-Rspam-User: X-HE-Tag: 1720614297-724809 X-HE-Meta: U2FsdGVkX1/dwSaYbZ5U/DE1rRiWxN5M4VX6xWN6/xkTI+tT5lpZhWQgD6exQSWWIwypWavdNUtxrpuTm4HTVGSGRtYDBNfzNYRf+LKvScgf4gcRO2yze6BXPMxfTgEEBUnhBesSAa4Jc4bfhEt0FAgSz2+oyc6vPa/JUyAvC6B1Y54gV0Ujslin1QAWGy4ZHPiE02nxkCNj7JJL4uQ+2d4NGN5LQXcLv6SxgSZ+Full9EcsfBqOdiNyswXQouHSWS0d0P4ehUFBbY672At8Iw0PfkeQbO/AR6V81Emx3pILwafWERJH8vyqE90F3PmdI5q7elDcuhhRueWn7BFTlJQbClpdYKMAyS6A7Yhy2HTNrHc7lrKZSYShCqE2AwWWw/9idWMScq+YTesJ5tNRrYXXyctd96/FCK1nmWKwWUxrzXLICVdnrowqM/iPq/RWkLZZf2tZPUWNS+p8NqHxNbceDndt0/T5hlY+69w2vg/H2PkqVoyAj41ERQ8z9c0Hnj1Pd8w5J+TWdb43a6nwpZVoDFsE++G+DNMTORPcxJYyiFQNgNpfqwoa4ndDup3b7hfqRdUfPRNb8Y9IN5FBs15fFjF2zQXpBQl60VVSupUqKqva9Lk1m64v9qvtT8fm5bO342ZueHC1x3TELPD61JjoTBm/Ia0M+5yNleBd6Wzjm6kctT520tz/rHZLoc905A7+u9BqujOxKylYXiixUlZ7BedNj8vF9GQy6/XTg9/SmzMjzU4jKahsMANk0Lkl3RJ04WnXsKwDMAxSwGplgW3RkJ/FZOCaOrkHZE4p+/IJxHLRllbeOeIVewUoRoLA5s83gexe/0edQlPQ0Rlgf5COmlAKTdeBuzSzBLBrj132HSCfewTfTKTlwGESqSaxamdm3mDSJHb7hiGeFLFznMmC1y2vys40TUOy9PRbPGPtZ6XC/zWwK/X8nxQzG7tQS9QhMWJezAtKvb9a52w vs/sLaaR UWlZUbRHiWgNyI4rK/2B5tJ3Qb5i+w3YUcvN1nqFK+GBBhxExLZexhqinSoKZ68peW83K/J9a/667+PtPCmjNCAJaBWkQwvqjsX99BI0/EW8EB+NLbcClgJmRElt++HIhLixNDR7ajG5Tkn5/7SF+5eOjW2YJH7bdNByjicVW/IYfIw0dmcouiJC0pyHQZOv9PxS+LtLnxL7lfisF9baOL+S9R59Qwfzl9zOUeZuNAdmiEMi8CAwQSXYfvan3kL668a+fnW8P6Jqeerxp6/sFgw7SNA/w5IUxKTg8ufotz2FWGxMXmrZIt4m1bg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 10/07/2024 01.17, Shakeel Butt wrote: > On Tue, Jul 09, 2024 at 01:20:48PM GMT, Jesper Dangaard Brouer wrote: >> 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. >> >> Help reviewers follow code: __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 >> --- >> V5: https://lore.kernel.org/all/171956951930.1897969.8709279863947931285.stgit@firesoul/ > > Does this version fixes the contention you are observing in production > for v5? No conclusions yet, as I'm still waiting for production servers to reboot into my experimental kernel. The V5 contention issue is observable via oneliner. That records lock contention and records the process that observe this: sudo bpftrace -e ' tracepoint:cgroup:cgroup_rstat_lock_contended { @cnt[comm]=count()} interval:s:1 {time("%H:%M:%S "); print(@cnt); clear(@cnt);}' Example output: 11:52:34 11:52:35 @cnt[kswapd4]: 114 @cnt[kswapd5]: 115 11:52:36 11:52:37 11:52:38 11:52:39 11:52:40 11:52:41 @cnt[kswapd2]: 124 @cnt[kswapd1]: 125 @cnt[kswapd7]: 137 @cnt[kswapd0]: 137 As we can see above kswapd processes, that must be flushing root-cgroup and should be waiting on cgrp_rstat_ongoing_flusher are seeing lock_contended. This indicate the race this patch address exists. For the record without this patch prod server (same HW generation), looks like this (so there is a significant improvement): 12:08:59 @cnt[kswapd2]: 565 @cnt[kswapd8]: 574 @cnt[kswapd9]: 575 @cnt[kswapd5]: 576 @cnt[kswapd6]: 577 @cnt[kswapd11]: 577 @cnt[kswapd3]: 578 @cnt[kswapd0]: 578 @cnt[kswapd4]: 688 @cnt[kswapd10]: 758 @cnt[kswapd1]: 768 @cnt[kswapd7]: 875 I'm going to send a V7 patch, because this V6 have an issue with usage of tracepoints for trylock scheme, that breaks my bpftrace script[1]. Coding it up now... I'm also adding a tracepoint for the cgrp_rstat_ongoing_flusher wait, such that we can measure this. I'm also adding a race indicator that can we read from this new tracepoint, as it will be helpful to proof/measure if this race is happening, and needed to tell the race apart from normal cgroup_rstat_lock_contended case. --Jesper [1] https://github.com/xdp-project/xdp-project/blob/master/areas/latency/cgroup_rstat_tracepoint.bt