[PATCH V3 1/2] cgroup/rstat: Helper functions for locking expose trylock

[PATCH V3 1/2] cgroup/rstat: Helper functions for locking expose trylock

[Jesper Dangaard Brouer]

Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org>
---
 kernel/cgroup/rstat.c |   40 ++++++++++++++++++++++++++++++----------
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c
index fb8b49437573..2a42be3a9bb3 100644
--- a/kernel/cgroup/rstat.c
+++ b/kernel/cgroup/rstat.c
@@ -279,17 +279,30 @@ __bpf_hook_end();
  * value -1 is used when obtaining the main lock else this is the CPU
  * number processed last.
  */
-static inline void __cgroup_rstat_lock(struct cgroup *cgrp, int cpu_in_loop)
+static inline bool __cgroup_rstat_trylock(struct cgroup *cgrp, int cpu_in_loop)
+{
+	bool locked;
+
+	locked = spin_trylock_irq(&cgroup_rstat_lock);
+	if (!locked)
+		trace_cgroup_rstat_lock_contended(cgrp, cpu_in_loop, !locked);
+
+	return locked;
+}
+
+static inline void __cgroup_rstat_lock(struct cgroup *cgrp, int cpu_in_loop,
+				       bool check_contention)
 	__acquires(&cgroup_rstat_lock)
 {
-	bool contended;
+	bool locked = false;
 
-	contended = !spin_trylock_irq(&cgroup_rstat_lock);
-	if (contended) {
-		trace_cgroup_rstat_lock_contended(cgrp, cpu_in_loop, contended);
+	if (check_contention)
+		locked = __cgroup_rstat_trylock(cgrp, cpu_in_loop);
+
+	if (!locked)
 		spin_lock_irq(&cgroup_rstat_lock);
-	}
-	trace_cgroup_rstat_locked(cgrp, cpu_in_loop, contended);
+
+	trace_cgroup_rstat_locked(cgrp, cpu_in_loop, !locked);
 }
 
 static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
@@ -328,7 +341,7 @@ static void cgroup_rstat_flush_locked(struct cgroup *cgrp)
 			__cgroup_rstat_unlock(cgrp, cpu);
 			if (!cond_resched())
 				cpu_relax();
-			__cgroup_rstat_lock(cgrp, cpu);
+			__cgroup_rstat_lock(cgrp, cpu, true);
 		}
 	}
 }
@@ -348,9 +361,16 @@ static void cgroup_rstat_flush_locked(struct cgroup *cgrp)
  */
 __bpf_kfunc void cgroup_rstat_flush(struct cgroup *cgrp)
 {
+	bool locked;
+
 	might_sleep();
 
-	__cgroup_rstat_lock(cgrp, -1);
+	locked = __cgroup_rstat_trylock(cgrp, -1);
+	if (!locked) {
+		/* Opportunity to ongoing flush detection */
+		__cgroup_rstat_lock(cgrp, -1, false);
+	}
+
 	cgroup_rstat_flush_locked(cgrp);
 	__cgroup_rstat_unlock(cgrp, -1);
 }
@@ -368,7 +388,7 @@ void cgroup_rstat_flush_hold(struct cgroup *cgrp)
 	__acquires(&cgroup_rstat_lock)
 {
 	might_sleep();
-	__cgroup_rstat_lock(cgrp, -1);
+	__cgroup_rstat_lock(cgrp, -1, true);
 	cgroup_rstat_flush_locked(cgrp);
 }
 

[PATCH V3 2/2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes

[Jesper Dangaard Brouer]

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 <hawk@kernel.org>
---
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 <linux/sched/cputime.h>
+#include <linux/completion.h>
 
 #include <linux/bpf.h>
 #include <linux/btf.h>
@@ -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)

Re: [PATCH V3 2/2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes

[Yosry Ahmed]

On Wed, Jun 26, 2024 at 2:18 PM Jesper Dangaard Brouer <hawk@kernel.org> 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.
>
> 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 <hawk@kernel.org>
> ---
> 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 <linux/sched/cputime.h>
> +#include <linux/completion.h>
>
>  #include <linux/bpf.h>
>  #include <linux/btf.h>
> @@ -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);

Thanks for sending this!

The reason why I suggested that the completion live in struct cgroup
is because there is a chance here that the flush completes and another
irrelevant flush starts between reading cgrp_rstat_ongoing_flusher and
calling wait_for_completion_interruptible_timeout().

This will cause the caller to wait for an irrelevant flush, which may
be fine because today the caller would wait for the lock anyway. Just
mentioning this in case you think this may happen enough to be a
problem.

Also, I like the idea of the timeout here, it bounds the flush wait
time. I am wondering if there's a way to log something when the
timeout is exceeded (which probably means flushing is taking too
long), or maybe have a debug counter if we suspect this may spam the
log.

Re: [PATCH V3 2/2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes

[Yosry Ahmed]

On Thu, Jun 27, 2024 at 3:33 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Wed, Jun 26, 2024 at 2:18 PM Jesper Dangaard Brouer <hawk@kernel.org> 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.
> >
> > 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 <hawk@kernel.org>
> > ---
> > 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 <linux/sched/cputime.h>
> > +#include <linux/completion.h>
> >
> >  #include <linux/bpf.h>
> >  #include <linux/btf.h>
> > @@ -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);
>
> Thanks for sending this!
>
> The reason why I suggested that the completion live in struct cgroup
> is because there is a chance here that the flush completes and another
> irrelevant flush starts between reading cgrp_rstat_ongoing_flusher and
> calling wait_for_completion_interruptible_timeout().
>
> This will cause the caller to wait for an irrelevant flush, which may
> be fine because today the caller would wait for the lock anyway. Just
> mentioning this in case you think this may happen enough to be a
> problem.

Actually, I think this can happen beyond the window I described above.
I think it's possible that a thread waits for the flush, then gets
woken up when complete_all() is called, but another flusher calls
reinit_completion() immediately. The woken up thread will observe
completion->done == 0 and go to sleep again.

I think most of these cases can be avoided if we make the completion
per cgroup. It is still possible to wait for more flushes than
necessary, but only if they are for the same cgroup.

Re: [PATCH V3 2/2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes

[Shakeel Butt]

On Thu, Jun 27, 2024 at 04:32:03AM GMT, Yosry Ahmed wrote:
> On Thu, Jun 27, 2024 at 3:33 AM Yosry Ahmed <yosryahmed@google.com> wrote:
[...]
> >
> > The reason why I suggested that the completion live in struct cgroup
> > is because there is a chance here that the flush completes and another
> > irrelevant flush starts between reading cgrp_rstat_ongoing_flusher and
> > calling wait_for_completion_interruptible_timeout().

Yes this can happen if flusher for irrelevant cgroup calls
reinit_completion() while the initial flusher was just about to call
wait_for_completion_interruptible_timeout().

> >
> > This will cause the caller to wait for an irrelevant flush, which may
> > be fine because today the caller would wait for the lock anyway. Just
> > mentioning this in case you think this may happen enough to be a
> > problem.
> 
> Actually, I think this can happen beyond the window I described above.
> I think it's possible that a thread waits for the flush, then gets
> woken up when complete_all() is called, but another flusher calls
> reinit_completion() immediately. The woken up thread will observe
> completion->done == 0 and go to sleep again.

I don't think it will go to sleep again as there is no retry.

> 
> I think most of these cases can be avoided if we make the completion
> per cgroup. It is still possible to wait for more flushes than
> necessary, but only if they are for the same cgroup.

Yeah, per-cgroup completion would avoid the problem of waiting for
irrelevant flush.

Re: [PATCH V3 2/2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes

[Jesper Dangaard Brouer]

On 27/06/2024 20.45, Shakeel Butt wrote:
> On Thu, Jun 27, 2024 at 04:32:03AM GMT, Yosry Ahmed wrote:
>> On Thu, Jun 27, 2024 at 3:33 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> [...]
>>>
>>> The reason why I suggested that the completion live in struct cgroup
>>> is because there is a chance here that the flush completes and another
>>> irrelevant flush starts between reading cgrp_rstat_ongoing_flusher and
>>> calling wait_for_completion_interruptible_timeout().
> 

I didn't add this per cgroup because I fear the race of adding a 
wait_for_completion on a cgroup that gets stuck there, but looking at 
the code the completion API should be able to avoid this.


> Yes this can happen if flusher for irrelevant cgroup calls
> reinit_completion() while the initial flusher was just about to call
> wait_for_completion_interruptible_timeout().
> 

Restoring two main functions to assist reviewer seeing the race:

On 26/06/2024 23.18, Jesper Dangaard Brouer wrote:
 > +#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
 > +		 * taking care of this, if we are a descendant.
 > +		 */
 > +		cgrp_ongoing = READ_ONCE(cgrp_rstat_ongoing_flusher);
 > +		if (!cgrp_ongoing)
 > +			goto retry;
 > +

Long wait/race here, can cause us to see an out-dated cgrp_ongoing.
And then another CPU manage to reach reinit_completion() below, before
execution continues here.

 > +		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);
 > +}


>>>
>>> This will cause the caller to wait for an irrelevant flush, which may
>>> be fine because today the caller would wait for the lock anyway. Just
>>> mentioning this in case you think this may happen enough to be a
>>> problem.

Yes, it would wait for an irrelevant flush.

>>
>> Actually, I think this can happen beyond the window I described above.
>> I think it's possible that a thread waits for the flush, then gets
>> woken up when complete_all() is called, but another flusher calls
>> reinit_completion() immediately. The woken up thread will observe
>> completion->done == 0 and go to sleep again.
> 
> I don't think it will go to sleep again as there is no retry.
> 
>>
>> I think most of these cases can be avoided if we make the completion
>> per cgroup. It is still possible to wait for more flushes than
>> necessary, but only if they are for the same cgroup.
> 
> Yeah, per-cgroup completion would avoid the problem of waiting for
> irrelevant flush.

Great, I will code up a version with per-cgroup completion.

--Jesper