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 D1A8ECD8CBD for ; Thu, 5 Sep 2024 17:32:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 576B76B008C; Thu, 5 Sep 2024 13:32:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5276F6B0093; Thu, 5 Sep 2024 13:32:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EEBA6B0095; Thu, 5 Sep 2024 13:32:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2128E6B008C for ; Thu, 5 Sep 2024 13:32:20 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B3E041607F5 for ; Thu, 5 Sep 2024 17:32:19 +0000 (UTC) X-FDA: 82531378398.03.9BED278 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf06.hostedemail.com (Postfix) with ESMTP id D824E18001C for ; Thu, 5 Sep 2024 17:32:17 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Biq5OvBX; spf=pass (imf06.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725557513; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=La3gWx3dLLSUBsyYmKlxjF/BBx5o3oL64jxWJcre0cY=; b=CZ3+fE3Pl+Lf49SNSaEIWKjSg+1B22JRW5xYpTHQ37gDy9UBWwJST0h5REG8hojXoxsRBE VsdYUbXWwepOWThmiBMAjZqccA/vBy01cOllw7IQkVT1OH4Pqn4cWFWTzKl4KvcDw6BtvC 456vhrVIEl4D6vJo5rvM8h1uZvGrQO4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Biq5OvBX; spf=pass (imf06.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725557513; a=rsa-sha256; cv=none; b=xZdct4XJJockc5QfOJp1/yfqarSZ5Jsx1f4uyM7n4Eudk/eGFy4PpQsXofAfyczQWLysHE ng4ZtWE+KJRCyq400dFtJrRKNvhWny/umX6yWJwgBKEhz+fTZKJBD8jkQ/YjlnZ/jVwGet ufWXRS7aL9qcG/P/J28mhMsznDOV88I= Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5c25554ec1eso1197342a12.1 for ; Thu, 05 Sep 2024 10:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725557536; x=1726162336; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=La3gWx3dLLSUBsyYmKlxjF/BBx5o3oL64jxWJcre0cY=; b=Biq5OvBXMXAVPXtDhx9vz4pRT9sV8YEuUnB4D0HF+0ILC8A+Cu6VWNMAJ82Uv5HXNg Pgx5qYqjLBl6S9PG9ixkxzswGZpbE13AOeJpgURVW1Xj0vBngQbc7+Zbd2an+tgZBCrt 72iTNuV/0TprxK/KIhWej30nJT4IcBQEf9B94fPVboPEkRJhMcDJel49uF1joCMnZDzn /IUSulSzwEdVZD5JYgFGoHTO0g3qmG0qEOMmvFh1ncJZamEXGeeJmt8/o0nS22pu9Ovo i7NU8dVBHSlgZhA/mwSuVCft58G23MuDfZfVgpEIoSpWSrA4uLc7a4QlY3cfmxPW/3bn Qg+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725557536; x=1726162336; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=La3gWx3dLLSUBsyYmKlxjF/BBx5o3oL64jxWJcre0cY=; b=mCHhYU/nreBEaejM2ukb9yMTg/4cGTVF47fYzDd7nQNky44o9sU6lN9598ubM0ddBT MLMjTjt9KKEi2OwzHDHgtyA4sJQC0kteo7k141+y+Jojd+3FjnPp1lpa49+FHzfTW+Ff SrvB89DvPQI6kTpO1RKp/92vRhHPe2u3G+jkOuGHv87ibZ6wFxUWZXJ49+OLnS6/KG7C Is7LK2T1OazmjmP4jJA2pYY/hVfS39JS11HAYs1QUQEvnM8u4qy84wz3DYm4qjk0YM/s /HOJwQyjVBoeZGkGZm5wcOfkB8m7IMJsmdu5HaAa+uqgOfTZkye9R7CBEXALDaoNYLL6 ScJw== X-Forwarded-Encrypted: i=1; AJvYcCWE+B57bNb2yBNT10+BjLLTcHYcTb6L7/UtVUW3ssX7qKo6lMBAyFVmN19ZUF7VOGJoRVPNSO5THw==@kvack.org X-Gm-Message-State: AOJu0YxcTFbZWvFQs3BaS7UhcDBRXy6xlET6bU4MHlJOApcVTEHKGnWI TFRT3XOmw4LN1Vj92AJRhljRpKNNAU9XrCQJq1kXoiPE5GX//l+rW0MTsuH9QEnLXUKrbQEpqdl OYIsVksrZ74YweFqwW0mzI6/P1/vPrgYVP1hg X-Google-Smtp-Source: AGHT+IHuEHg6iFJmi96ZdHpr/erJcBCYC0Xlx/zvHuaYnuSuywkb734wF9h4NCsjsZ87amd8NqQi2xJ/YplnroqMhL8= X-Received: by 2002:a17:907:ea3:b0:a86:a12b:2cea with SMTP id a640c23a62f3a-a897fad6ff4mr2128470966b.67.1725557535314; Thu, 05 Sep 2024 10:32:15 -0700 (PDT) MIME-Version: 1.0 References: <172547884995.206112.808619042206173396.stgit@firesoul> In-Reply-To: From: Yosry Ahmed Date: Thu, 5 Sep 2024 10:31:37 -0700 Message-ID: Subject: Re: [PATCH V10] cgroup/rstat: Avoid flushing if there is an ongoing root flush To: Jesper Dangaard Brouer Cc: tj@kernel.org, cgroups@vger.kernel.org, shakeel.butt@linux.dev, hannes@cmpxchg.org, lizefan.x@bytedance.com, longman@redhat.com, kernel-team@cloudflare.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, mfleming@cloudflare.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Stat-Signature: ooeiw4u5miwpq1xwfhjd1nbr9uzinzdj X-Rspamd-Queue-Id: D824E18001C X-Rspamd-Server: rspam11 X-HE-Tag: 1725557537-855447 X-HE-Meta: U2FsdGVkX18WraAa1qf5VHenyHYpjplNHXhlfVMQIWd3NG9483VMxTNUprzZxNOfLdbeVAiEWgVdvHf1b7idB7JCqzmlN0DliFQKR67CCDBNSBvnWrNlJe7eTipIP9xi5q//m3bTqlmofGO8PJgZBgxbyBCzip7NxTGxiF7/ceCJwMiJC6tc6jTVcBJQ8yrhN6tRrrh1yGH9a+MsoIf2BENzDL9ElBj8l4ddAucaPi6gjLYIwUEjHdkV7IvC71Qx2EKTbzNkE87szi9KpZkIQTjWmEE1Yg/POnI+nC0+d4Y3IWpYXVJzkxhdKFqdOXnt+Kf+QpiDBCh2sq0G2ORliUoy2NLezsGMFmze/Y2li/mvl4EF+kg6+FpL07f1ccwQOBuLGPg984pitFoQ8r4YhwYOxlZ31422EmIjMOkvuTRKV7txUl4m39vGKyv8NTAEy7fLqz/5lIM8a7sawDOXBAIvZib1b20a4HHwQWqHSY3cQla2fGijgbpyebekMrq/VgH14IBjsi1CYqI0BKaG09RMz4Opao9mcnC3vxXGKF4xtHB0rQ5iMOn7NGpRK5wA+zScbgLZvz5P1FQZ05DNbhxDrbwQ4tdUtCtwem9dWdP+Awv48JPzaxU3poAKXNnhQcUFAj8r3fuP7MkMlrm+66IoaWDxlLNE8PHbbVCYUbQ3BTNF1eUrKbrY6mPdvOmBBAZX+llgLe5atvT58pQ0kYSJcXU6uJHi2VxrXqrI14b+IdTmlhagy0AXvpVjEkAgZfkUutRtvG9sRItz/8UFgGFIhQE4Z1RQ8OPRBg49ingZwiy2jNAzzKkSSPo/dmjDETP1viDyODVSjFwoZThrV0V6TfQyC8TlnpQHgliD6OccyypZCab936jugxMukmC8QU/O/N/NYeoS0EQgCNuyRSpBXFvpMxIQk5lmQtfCyldGgFcayZgt7soFUcCGhTR2u3CyDLSjzt/+TlNQhzv pYZ5VJvz +7F9zyRQ0FVPGyD3sEh6WR/FFU8AO+EouGZgNOoL0xwg37J3kJIcUus/mEGFdsr80lwDEDNF4d/3VOe33yuV5knA/APCoJTASDkFz/j0frDUAv9BWKA15/CLlHpg9FrbuJREjTAavdcgNuhVub5/mpyq8f7JQ1jhycPgW7osb/rXI8WDB699z9jh0f2KR3/5g73Op9tlUqJ5sK4KusOrO21V6qiE56JL34pGALu20dBDr2XiGSoPzKIv19g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: [..] > >> @@ -299,6 +301,67 @@ static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop) > >> spin_unlock_irq(&cgroup_rstat_lock); > >> } > >> > >> +static inline bool cgroup_is_root(struct cgroup *cgrp) > >> +{ > >> + return cgroup_parent(cgrp) == NULL; > >> +} > >> + > >> +/** > >> + * cgroup_rstat_trylock_flusher - Trylock that checks for on ongoing flusher > >> + * @cgrp: target cgroup > >> + * > >> + * Function return value follow trylock semantics. Returning true when lock is > >> + * obtained. Returning false when not locked and it detected flushing can be > >> + * skipped as another ongoing flusher is taking care of the flush. > >> + * > >> + * For callers that depend on flush completing before returning a strict option > >> + * is provided. > >> + */ > >> +static bool cgroup_rstat_trylock_flusher(struct cgroup *cgrp, bool strict) > >> +{ > >> + struct cgroup *ongoing; > >> + > >> + if (strict) > >> + goto lock; > >> + > >> + /* > >> + * Check if ongoing flusher is already taking care of this. Descendant > >> + * check is necessary due to cgroup v1 supporting multiple root's. > >> + */ > >> + ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher); > >> + if (ongoing && cgroup_is_descendant(cgrp, ongoing)) > >> + return false; > > > > Why did we drop the agreed upon method of waiting until the flushers > > are done? This is now a much more intrusive patch which makes all > > flushers skip if a root is currently flushing. This causes > > user-visible problems and is something that I worked hard to fix. I > > thought we got good results with waiting for the ongoing flusher as > > long as it is a root? What changed? > > > > I disagree with the idea of waiting until the flusher is done. > As Shakeel have pointed out before, we don't need accurate stats. > This caused issues and 'completions' complicated the code too much. I think Shakeel was referring specifically to the flush in the reclaim path. I don't think this statement holds for all cgroup flushers, especially those exposed to userspace. > > When multiple (12) kswapd's are running, then waiting for ongoing > flusher will cause us to delay all other kswapd threads, for on my > production system approx 24 ms (see attached prod graph). > Matt (Cc) is currently[1] looking into page alloc failures that are > happening across the fleet, when NIC RX packets as those allocs are > GFP_ATOMIC. So, basically kswapd isn't reclaiming memory fast enough on > our systems, which could be related to this flush latency. (Quick calc, > prod server RX 1,159,695 pps, thus in 24 ms period 27,832 packets are > handled, that exceed RX ring size 1024). > > [1] > https://lore.kernel.org/all/CAGis_TWzSu=P7QJmjD58WWiu3zjMTVKSzdOwWE8ORaGytzWJwQ@mail.gmail.com/ > > For this reason, I don't want to have code that waits for ongoing > flushers to finish. This is why I changed the code. My understanding was that the previous versions solved most of the problem. However, if it's not enough and we need to completely skip the flush, then I don't think this patch is the right way to go. This affects all flushers, not just the reclaim path, and not even just the memcg flushers. Waiting for ongoing flushers was a generic approach that should work for all flushers, but completely skipping the flush is not. If your problem is specifically the flush in the reclaim path, then Shakeel's patch to replace that flush with the ratelimited version should fix your problem. It was already merged into mm-stable (so headed toward v6.11 AFAICT). > > > > You also never addressed my concern here about 'ongoing' while we are > > accessing it, and never responded to my question in v8 about expanding > > this to support non-root cgroups once we shift to a mutex. > > > > I don't think we should expand this to non-root cgroups. My production > data from this V10 shows we don't need this for non-root cgroups. Right, because you are concerned with the flush in the kswapd path specifically. This patch touches affects much more than that. > > > > I don't appreciate the silent yet drastic change made in this version > > and without addressing concerns raised in previous versions. Please > > let me know if I missed something. > > > > IMHO we needed a drastic change, because patch was getting too > complicated, and my production experiments showed that it was no-longer > solving the contention issue (due to allowing non-root cgroups to become > ongoing). I thought we agreed to wait for the ongoing flusher to complete, but only allow root cgroups to become the ongoing flusher (at least initially). Not sure what changed. > > Production servers with this V10 patch applied shows HUGE improvements. > Let me grab a graf showing level-0 contention events being reduced from > 1360 event/sec to 0.277 events/sec. I had to change to a log-scale graf > to make improvement visible. The wait-time is also basically gone. The > improvements are so convincing and highly needed, that we are going to > deploy this improvement. I usually have a very strong upstream first > principle, but we simply cannot wait any-longer for a solution to this > production issue. Of course there is a huge improvement, you are completely skipping the flush :) You are gaining a lot of performance but you'll also lose something, there is no free lunch here. This may be an acceptable tradeoff for the reclaim path, but definitely not for all flushers. > > > >> + > >> + /* Grab right to be ongoing flusher */ > >> + if (!ongoing && cgroup_is_root(cgrp)) { > >> + struct cgroup *old; > >> + > >> + old = cmpxchg(&cgrp_rstat_ongoing_flusher, NULL, cgrp); > >> + if (old) { > >> + /* Lost race for being ongoing flusher */ > >> + if (cgroup_is_descendant(cgrp, old)) > >> + return false; > >> + } > >> + /* Due to lock yield combined with strict mode record ID */ > >> + WRITE_ONCE(cgrp_rstat_ongoing_flusher_ID, current); > > > > I am not sure I understand why we need this, do you mind elaborating? > > Let me expand the comment. Due to lock yield an ongoing (root) flusher > can yield the lock, which would allow a root flush in strict mode to > obtain the lock, which then in the unlock call (see below) will clear > cgrp_rstat_ongoing_flusher (as cgrp in both cases have "root" cgrp ptr), > unless it have this flush_ID to tell them apart. The pointers should be different for different roots though, right? Why do we need the ID to tell them apart? I am not sure I follow.