linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosryahmed@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Shakeel Butt" <shakeelb@google.com>,
	"Muchun Song" <muchun.song@linux.dev>,
	"Ivan Babrou" <ivan@cloudflare.com>, "Tejun Heo" <tj@kernel.org>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Waiman Long" <longman@redhat.com>,
	kernel-team@cloudflare.com, "Wei Xu" <weixugc@google.com>,
	"Greg Thelen" <gthelen@google.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Yosry Ahmed" <yosryahmed@google.com>
Subject: [PATCH v2 4/5] mm: workingset: move the stats flush into workingset_test_recent()
Date: Tue, 10 Oct 2023 03:21:15 +0000	[thread overview]
Message-ID: <20231010032117.1577496-5-yosryahmed@google.com> (raw)
In-Reply-To: <20231010032117.1577496-1-yosryahmed@google.com>

The workingset code flushes the stats in workingset_refault() to get
accurate stats of the eviction memcg. In preparation for more scoped
flushed and passing the eviction memcg to the flush call, move the call
to workingset_test_recent() where we have a pointer to the eviction
memcg.

The flush call is sleepable, and cannot be made in an rcu read section.
Hence, minimize the rcu read section by also moving it into
workingset_test_recent(). Furthermore, instead of holding the rcu read
lock throughout workingset_test_recent(), only hold it briefly to get a
ref on the eviction memcg. This allows us to make the flush call after
we get the eviction memcg.

As for workingset_refault(), nothing else there appears to be protected
by rcu. The memcg of the faulted folio (which is not necessarily the
same as the eviction memcg) is protected by the folio lock, which is
held from all callsites. Add a VM_BUG_ON() to make sure this doesn't
change from under us.

No functional change intended.

Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
---
 mm/workingset.c | 36 ++++++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/mm/workingset.c b/mm/workingset.c
index b192e44a0e7c..a573be6c59fd 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -425,8 +425,16 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset)
 	struct pglist_data *pgdat;
 	unsigned long eviction;
 
-	if (lru_gen_enabled())
-		return lru_gen_test_recent(shadow, file, &eviction_lruvec, &eviction, workingset);
+	rcu_read_lock();
+
+	if (lru_gen_enabled()) {
+		bool recent = lru_gen_test_recent(shadow, file,
+				&eviction_lruvec, &eviction, workingset);
+
+		rcu_read_unlock();
+		return recent;
+	}
+
 
 	unpack_shadow(shadow, &memcgid, &pgdat, &eviction, workingset);
 	eviction <<= bucket_order;
@@ -448,8 +456,16 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset)
 	 * configurations instead.
 	 */
 	eviction_memcg = mem_cgroup_from_id(memcgid);
-	if (!mem_cgroup_disabled() && !eviction_memcg)
+	if (!mem_cgroup_disabled() &&
+	    (!eviction_memcg || !mem_cgroup_tryget(eviction_memcg))) {
+		rcu_read_unlock();
 		return false;
+	}
+
+	rcu_read_unlock();
+
+	/* Flush stats (and potentially sleep) outside the RCU read section */
+	mem_cgroup_flush_stats_ratelimited();
 
 	eviction_lruvec = mem_cgroup_lruvec(eviction_memcg, pgdat);
 	refault = atomic_long_read(&eviction_lruvec->nonresident_age);
@@ -493,6 +509,7 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset)
 		}
 	}
 
+	mem_cgroup_put(eviction_memcg);
 	return refault_distance <= workingset_size;
 }
 
@@ -519,19 +536,16 @@ void workingset_refault(struct folio *folio, void *shadow)
 		return;
 	}
 
-	/* Flush stats (and potentially sleep) before holding RCU read lock */
-	mem_cgroup_flush_stats_ratelimited();
-
-	rcu_read_lock();
-
 	/*
 	 * The activation decision for this folio is made at the level
 	 * where the eviction occurred, as that is where the LRU order
 	 * during folio reclaim is being determined.
 	 *
 	 * However, the cgroup that will own the folio is the one that
-	 * is actually experiencing the refault event.
+	 * is actually experiencing the refault event. Make sure the folio is
+	 * locked to guarantee folio_memcg() stability throughout.
 	 */
+	VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
 	nr = folio_nr_pages(folio);
 	memcg = folio_memcg(folio);
 	pgdat = folio_pgdat(folio);
@@ -540,7 +554,7 @@ void workingset_refault(struct folio *folio, void *shadow)
 	mod_lruvec_state(lruvec, WORKINGSET_REFAULT_BASE + file, nr);
 
 	if (!workingset_test_recent(shadow, file, &workingset))
-		goto out;
+		return;
 
 	folio_set_active(folio);
 	workingset_age_nonresident(lruvec, nr);
@@ -556,8 +570,6 @@ void workingset_refault(struct folio *folio, void *shadow)
 		lru_note_cost_refault(folio);
 		mod_lruvec_state(lruvec, WORKINGSET_RESTORE_BASE + file, nr);
 	}
-out:
-	rcu_read_unlock();
 }
 
 /**
-- 
2.42.0.609.gbb76f46606-goog



  parent reply	other threads:[~2023-10-10  3:21 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10  3:21 [PATCH v2 0/5] mm: memcg: subtree stats flushing and thresholds Yosry Ahmed
2023-10-10  3:21 ` [PATCH v2 1/5] mm: memcg: change flush_next_time to flush_last_time Yosry Ahmed
2023-10-10  3:21 ` [PATCH v2 2/5] mm: memcg: move vmstats structs definition above flushing code Yosry Ahmed
2023-10-10  3:21 ` [PATCH v2 3/5] mm: memcg: make stats flushing threshold per-memcg Yosry Ahmed
2023-10-10  3:24   ` Yosry Ahmed
2023-10-10 20:45   ` Shakeel Butt
2023-10-10 21:02     ` Yosry Ahmed
2023-10-10 22:21       ` Yosry Ahmed
2023-10-11  0:36         ` Shakeel Butt
2023-10-11  1:48           ` Yosry Ahmed
2023-10-11 12:45             ` Shakeel Butt
2023-10-12  3:13               ` Yosry Ahmed
2023-10-12  8:01                 ` Yosry Ahmed
2023-10-12  8:04                 ` Yosry Ahmed
2023-10-12 13:29                   ` Johannes Weiner
2023-10-12 23:28                     ` Yosry Ahmed
2023-10-13  2:33                       ` Johannes Weiner
2023-10-13  2:38                         ` Yosry Ahmed
2023-10-12 13:35                   ` Shakeel Butt
2023-10-12 15:10                     ` Yosry Ahmed
2023-10-12 21:05                       ` Yosry Ahmed
2023-10-12 21:16                         ` Shakeel Butt
2023-10-12 21:19                           ` Yosry Ahmed
2023-10-12 21:38                             ` Shakeel Butt
2023-10-12 22:23                               ` Yosry Ahmed
2023-10-14 23:08                                 ` Andrew Morton
2023-10-16 18:42                                   ` Yosry Ahmed
2023-10-17 23:52                                   ` Yosry Ahmed
2023-10-18  8:22                                 ` Oliver Sang
2023-10-18  8:54                                   ` Yosry Ahmed
2023-10-20 16:17   ` kernel test robot
2023-10-20 17:23     ` Shakeel Butt
2023-10-20 17:42       ` Yosry Ahmed
2023-10-23  1:25         ` Feng Tang
2023-10-23 18:25           ` Yosry Ahmed
2023-10-24  2:13             ` Yosry Ahmed
2023-10-24  6:56               ` Oliver Sang
2023-10-24  7:14                 ` Yosry Ahmed
2023-10-25  6:09                   ` Oliver Sang
2023-10-25  6:22                     ` Yosry Ahmed
2023-10-25 17:06                       ` Shakeel Butt
2023-10-25 18:36                         ` Yosry Ahmed
2023-10-10  3:21 ` Yosry Ahmed [this message]
2023-10-10  3:21 ` [PATCH v2 5/5] mm: memcg: restore subtree stats flushing Yosry Ahmed
2023-10-10 16:48 ` [PATCH v2 0/5] mm: memcg: subtree stats flushing and thresholds domenico cerasuolo
2023-10-10 19:01   ` Yosry Ahmed
2023-10-18 21:12 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231010032117.1577496-5-yosryahmed@google.com \
    --to=yosryahmed@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=ivan@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=longman@redhat.com \
    --cc=mhocko@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=tj@kernel.org \
    --cc=weixugc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).