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

[PATCH V4 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 V4 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>
---
V3: https://lore.kernel.org/all/171943668946.1638606.1320095353103578332.stgit@firesoul/
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/

 include/linux/cgroup-defs.h |    2 +
 kernel/cgroup/rstat.c       |   64 ++++++++++++++++++++++++++++++++++++-------
 2 files changed, 55 insertions(+), 11 deletions(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index b36690ca0d3f..a33b37514c29 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -548,6 +548,8 @@ struct cgroup {
 #ifdef CONFIG_BPF_SYSCALL
 	struct bpf_local_storage __rcu  *bpf_cgrp_storage;
 #endif
+	/* completion queue for cgrp_rstat_ongoing_flusher */
+	struct completion flush_done;
 
 	/* All ancestors including self */
 	struct cgroup *ancestors[];
diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c
index 2a42be3a9bb3..a98af43bdce7 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 = NULL;
+static DECLARE_COMPLETION(cgrp_rstat_flusher_done);
 
 static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu);
 
@@ -312,6 +315,45 @@ static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
 	spin_unlock_irq(&cgroup_rstat_lock);
 }
 
+#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)
+{
+	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 && cgroup_is_descendant(cgrp, cgrp_ongoing)) {
+			wait_for_completion_interruptible_timeout(
+				&cgrp_ongoing->flush_done, MAX_WAIT);
+
+			return false;
+		}
+		__cgroup_rstat_lock(cgrp, -1, false);
+	}
+	/* Obtained lock, record this cgrp as the ongoing flusher */
+	if (!READ_ONCE(cgrp_rstat_ongoing_flusher)) {
+		reinit_completion(&cgrp->flush_done);
+		WRITE_ONCE(cgrp_rstat_ongoing_flusher, cgrp);
+	}
+
+	return true; /* locked */
+}
+
+static void cgroup_rstat_unlock_flusher(struct cgroup *cgrp)
+{
+	/* Detect if we are the ongoing flusher */
+	if (cgrp == READ_ONCE(cgrp_rstat_ongoing_flusher)) {
+		WRITE_ONCE(cgrp_rstat_ongoing_flusher, NULL);
+		complete_all(&cgrp->flush_done);
+	}
+	__cgroup_rstat_unlock(cgrp, -1);
+}
+
 /* see cgroup_rstat_flush() */
 static void cgroup_rstat_flush_locked(struct cgroup *cgrp)
 	__releases(&cgroup_rstat_lock) __acquires(&cgroup_rstat_lock)
@@ -361,18 +403,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 +425,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 +439,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)
@@ -421,6 +461,8 @@ int cgroup_rstat_init(struct cgroup *cgrp)
 		u64_stats_init(&rstatc->bsync);
 	}
 
+	init_completion(&cgrp->flush_done);
+
 	return 0;
 }
 

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

[Shakeel Butt]

On Thu, Jun 27, 2024 at 11:18:56PM 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.
> 
> To help reviewer follow code: When the Per-CPU-Pages (PCP) freelist is
> empty,

Remove the "When the Per-CPU-Pages (PCP) freelist is empty" as there are
a lot more conditions needed for the waking up kswapds which are not
needed to be explained here. Just "__alloc_pages_slowpath waking up
kswapds given the allocation context" or similar text should suffice.

> __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>
> ---
> V3: https://lore.kernel.org/all/171943668946.1638606.1320095353103578332.stgit@firesoul/
> 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/
> 
>  include/linux/cgroup-defs.h |    2 +
>  kernel/cgroup/rstat.c       |   64 ++++++++++++++++++++++++++++++++++++-------
>  2 files changed, 55 insertions(+), 11 deletions(-)
> 
> diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
> index b36690ca0d3f..a33b37514c29 100644
> --- a/include/linux/cgroup-defs.h
> +++ b/include/linux/cgroup-defs.h
> @@ -548,6 +548,8 @@ struct cgroup {
>  #ifdef CONFIG_BPF_SYSCALL
>  	struct bpf_local_storage __rcu  *bpf_cgrp_storage;
>  #endif
> +	/* completion queue for cgrp_rstat_ongoing_flusher */
> +	struct completion flush_done;
>  
>  	/* All ancestors including self */
>  	struct cgroup *ancestors[];
> diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c
> index 2a42be3a9bb3..a98af43bdce7 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 = NULL;
> +static DECLARE_COMPLETION(cgrp_rstat_flusher_done);

cgrp_rstat_flusher_done is not needed anymore.

>  
>  static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu);
>  
> @@ -312,6 +315,45 @@ static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
>  	spin_unlock_irq(&cgroup_rstat_lock);
>  }
>  
> +#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)
> +{
> +	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 && cgroup_is_descendant(cgrp, cgrp_ongoing)) {

I wonder if READ_ONCE() and cgroup_is_descendant() needs to happen
within in rcu section. On a preemptable kernel, let's say we got
preempted in between them, the flusher was unrelated and got freed
before we get the CPU. In that case we are accessing freed memory.

> +			wait_for_completion_interruptible_timeout(
> +				&cgrp_ongoing->flush_done, MAX_WAIT);
> +
> +			return false;
> +		}
> +		__cgroup_rstat_lock(cgrp, -1, false);
> +	}
> +	/* Obtained lock, record this cgrp as the ongoing flusher */
> +	if (!READ_ONCE(cgrp_rstat_ongoing_flusher)) {

Can the above condition will ever be false?

> +		reinit_completion(&cgrp->flush_done);
> +		WRITE_ONCE(cgrp_rstat_ongoing_flusher, cgrp);
> +	}
> +
> +	return true; /* locked */
> +}
> +
> +static void cgroup_rstat_unlock_flusher(struct cgroup *cgrp)
> +{
> +	/* Detect if we are the ongoing flusher */
> +	if (cgrp == READ_ONCE(cgrp_rstat_ongoing_flusher)) {

Same.

> +		WRITE_ONCE(cgrp_rstat_ongoing_flusher, NULL);
> +		complete_all(&cgrp->flush_done);
> +	}
> +	__cgroup_rstat_unlock(cgrp, -1);
> +}
> +
>  /* see cgroup_rstat_flush() */
>  static void cgroup_rstat_flush_locked(struct cgroup *cgrp)
>  	__releases(&cgroup_rstat_lock) __acquires(&cgroup_rstat_lock)
> @@ -361,18 +403,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 +425,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 +439,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)
> @@ -421,6 +461,8 @@ int cgroup_rstat_init(struct cgroup *cgrp)
>  		u64_stats_init(&rstatc->bsync);
>  	}
>  
> +	init_completion(&cgrp->flush_done);
> +
>  	return 0;
>  }
>  
> 
> 

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

[Jesper Dangaard Brouer]

On 28/06/2024 01.34, Shakeel Butt wrote:
> On Thu, Jun 27, 2024 at 11:18:56PM 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.
>>
>> To help reviewer follow code: When the Per-CPU-Pages (PCP) freelist is
>> empty,
> 
> Remove the "When the Per-CPU-Pages (PCP) freelist is empty" as there are
> a lot more conditions needed for the waking up kswapds which are not
> needed to be explained here. Just "__alloc_pages_slowpath waking up
> kswapds given the allocation context" or similar text should suffice.
> 

Agree.

>> __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>
>> ---
>> V3: https://lore.kernel.org/all/171943668946.1638606.1320095353103578332.stgit@firesoul/
>> 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/
>>
>>   include/linux/cgroup-defs.h |    2 +
>>   kernel/cgroup/rstat.c       |   64 ++++++++++++++++++++++++++++++++++++-------
>>   2 files changed, 55 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
>> index b36690ca0d3f..a33b37514c29 100644
>> --- a/include/linux/cgroup-defs.h
>> +++ b/include/linux/cgroup-defs.h
>> @@ -548,6 +548,8 @@ struct cgroup {
>>   #ifdef CONFIG_BPF_SYSCALL
>>   	struct bpf_local_storage __rcu  *bpf_cgrp_storage;
>>   #endif
>> +	/* completion queue for cgrp_rstat_ongoing_flusher */
>> +	struct completion flush_done;
>>   
>>   	/* All ancestors including self */
>>   	struct cgroup *ancestors[];
>> diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c
>> index 2a42be3a9bb3..a98af43bdce7 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 = NULL;
>> +static DECLARE_COMPLETION(cgrp_rstat_flusher_done);
> 
> cgrp_rstat_flusher_done is not needed anymore.
> 

True, I already fixed this yesterday, when reading the patch email myself.

>>   
>>   static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu);
>>   
>> @@ -312,6 +315,45 @@ static inline void __cgroup_rstat_unlock(struct cgroup *cgrp, int cpu_in_loop)
>>   	spin_unlock_irq(&cgroup_rstat_lock);
>>   }
>>   
>> +#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)
>> +{
>> +	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 && cgroup_is_descendant(cgrp, cgrp_ongoing)) {
> 
> I wonder if READ_ONCE() and cgroup_is_descendant() needs to happen
> within in rcu section. On a preemptable kernel, let's say we got
> preempted in between them, the flusher was unrelated and got freed
> before we get the CPU. In that case we are accessing freed memory.
> 

I have to think about this some more.

>> +			wait_for_completion_interruptible_timeout(
>> +				&cgrp_ongoing->flush_done, MAX_WAIT);
>> +
>> +			return false;
>> +		}
>> +		__cgroup_rstat_lock(cgrp, -1, false);
>> +	}
>> +	/* Obtained lock, record this cgrp as the ongoing flusher */
>> +	if (!READ_ONCE(cgrp_rstat_ongoing_flusher)) {
> 
> Can the above condition will ever be false?
> 

Yes, I think so, because I realized that cgroup_rstat_flush_locked() can
release/"yield" the lock.  Thus, other CPUs/threads have a chance to
call cgroup_rstat_flush, and try to become the "ongoing-flusher".

With this realization, my __cgroup_rstat_trylock() "signal" to detect
ongoing-flushers is also not a good signal.  I think we/I should move
the ongoing_flusher detection before attempting to aquire the lock.
If doing so, I'm considering adding a tracepoint after
wait_for_completion() to help us see if code is behaving as expected in
prod env.


>> +		reinit_completion(&cgrp->flush_done);
>> +		WRITE_ONCE(cgrp_rstat_ongoing_flusher, cgrp);
>> +	}
>> +
>> +	return true; /* locked */
>> +}
>> +
>> +static void cgroup_rstat_unlock_flusher(struct cgroup *cgrp)
>> +{
>> +	/* Detect if we are the ongoing flusher */
>> +	if (cgrp == READ_ONCE(cgrp_rstat_ongoing_flusher)) {
> 
> Same.

Same explaination as above.

> 
>> +		WRITE_ONCE(cgrp_rstat_ongoing_flusher, NULL);
>> +		complete_all(&cgrp->flush_done);
>> +	}
>> +	__cgroup_rstat_unlock(cgrp, -1);
>> +}
>> +
>>   /* see cgroup_rstat_flush() */
>>   static void cgroup_rstat_flush_locked(struct cgroup *cgrp)
>>   	__releases(&cgroup_rstat_lock) __acquires(&cgroup_rstat_lock)
>> @@ -361,18 +403,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 +425,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 +439,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)
>> @@ -421,6 +461,8 @@ int cgroup_rstat_init(struct cgroup *cgrp)
>>   		u64_stats_init(&rstatc->bsync);
>>   	}
>>   
>> +	init_completion(&cgrp->flush_done);
>> +
>>   	return 0;
>>   }
>>   
>>
>>

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

[Yosry Ahmed]

[..]
> >> +    /* Obtained lock, record this cgrp as the ongoing flusher */
> >> +    if (!READ_ONCE(cgrp_rstat_ongoing_flusher)) {
> >
> > Can the above condition will ever be false?
> >
>
> Yes, I think so, because I realized that cgroup_rstat_flush_locked() can
> release/"yield" the lock.  Thus, other CPUs/threads have a chance to
> call cgroup_rstat_flush, and try to become the "ongoing-flusher".

Right, there may actually be multiple ongoing flushers. I am now
wondering if it would be better if we drop cgrp_rstat_ongoing_flusher
completely, add a per-cgroup under_flush boolean/flag, and have the
cgroup iterate its parents here to check if any of them is under_flush
and wait for it instead.

Yes, we have to add parent iteration here, but I think it may be fine
because the flush path is already expensive. This will allow us to
detect if any ongoing flush is overlapping with us, not just the one
that happened to update cgrp_rstat_ongoing_flusher first.

WDYT?

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

[Jesper Dangaard Brouer]

On 29/06/2024 00.15, Yosry Ahmed wrote:
> [..]
>>>> +    /* Obtained lock, record this cgrp as the ongoing flusher */
>>>> +    if (!READ_ONCE(cgrp_rstat_ongoing_flusher)) {
>>>
>>> Can the above condition will ever be false?
>>>
>>
>> Yes, I think so, because I realized that cgroup_rstat_flush_locked() can
>> release/"yield" the lock.  Thus, other CPUs/threads have a chance to
>> call cgroup_rstat_flush, and try to become the "ongoing-flusher".
> 
> Right, there may actually be multiple ongoing flushers. I am now
> wondering if it would be better if we drop cgrp_rstat_ongoing_flusher
> completely, add a per-cgroup under_flush boolean/flag, and have the
> cgroup iterate its parents here to check if any of them is under_flush
> and wait for it instead.
> 
> Yes, we have to add parent iteration here, but I think it may be fine
> because the flush path is already expensive. This will allow us to
> detect if any ongoing flush is overlapping with us, not just the one
> that happened to update cgrp_rstat_ongoing_flusher first.
> 
> WDYT?

No, I don't think we should complicate the code to "support" multiple
ongoing flushers (there is no parallel execution of these). The lock
yielding cause the (I assume) unintended side-effect that multiple
ongoing flushers can exist.  We should work towards only having a single
ongoing flusher.

With the current kswapd rstat contention issue, yielding the lock in the
loop, creates the worst possible case of cache-line trashing, as these
kthreads run on 12 different NUMA nodes.

I'm working towards changing rstat lock to a mutex.  When doing so, we
should not yield the lock in the loop.  This will guarantee only having
a single ongoing flusher, and reduce cache-line trashing.

--Jesper

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

[Yosry Ahmed]

On Tue, Jul 2, 2024 at 3:35 AM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>
>
>
> On 29/06/2024 00.15, Yosry Ahmed wrote:
> > [..]
> >>>> +    /* Obtained lock, record this cgrp as the ongoing flusher */
> >>>> +    if (!READ_ONCE(cgrp_rstat_ongoing_flusher)) {
> >>>
> >>> Can the above condition will ever be false?
> >>>
> >>
> >> Yes, I think so, because I realized that cgroup_rstat_flush_locked() can
> >> release/"yield" the lock.  Thus, other CPUs/threads have a chance to
> >> call cgroup_rstat_flush, and try to become the "ongoing-flusher".
> >
> > Right, there may actually be multiple ongoing flushers. I am now
> > wondering if it would be better if we drop cgrp_rstat_ongoing_flusher
> > completely, add a per-cgroup under_flush boolean/flag, and have the
> > cgroup iterate its parents here to check if any of them is under_flush
> > and wait for it instead.
> >
> > Yes, we have to add parent iteration here, but I think it may be fine
> > because the flush path is already expensive. This will allow us to
> > detect if any ongoing flush is overlapping with us, not just the one
> > that happened to update cgrp_rstat_ongoing_flusher first.
> >
> > WDYT?
>
> No, I don't think we should complicate the code to "support" multiple
> ongoing flushers (there is no parallel execution of these). The lock
> yielding cause the (I assume) unintended side-effect that multiple
> ongoing flushers can exist.  We should work towards only having a single
> ongoing flusher.
>
> With the current kswapd rstat contention issue, yielding the lock in the
> loop, creates the worst possible case of cache-line trashing, as these
> kthreads run on 12 different NUMA nodes.
>
> I'm working towards changing rstat lock to a mutex.  When doing so, we
> should not yield the lock in the loop.  This will guarantee only having
> a single ongoing flusher, and reduce cache-line trashing.

If the direction we are heading in is not supporting multiple ongoing
flushers then sure, that makes sense. But if we plan to continue
supporting multiple ongoing flushers, then I think we should fully
commit to it. Let's just avoid a halfway support.

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

[Jesper Dangaard Brouer]

On 28/06/2024 11.39, Jesper Dangaard Brouer wrote:
> 
> 
> On 28/06/2024 01.34, Shakeel Butt wrote:
>> On Thu, Jun 27, 2024 at 11:18:56PM 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.
>>>
[...]
>>>   static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu);
>>> @@ -312,6 +315,45 @@ static inline void __cgroup_rstat_unlock(struct 
>>> cgroup *cgrp, int cpu_in_loop)
>>>       spin_unlock_irq(&cgroup_rstat_lock);
>>>   }
>>> +#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)
>>> +{
>>> +    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 && cgroup_is_descendant(cgrp, cgrp_ongoing)) {
>>
>> I wonder if READ_ONCE() and cgroup_is_descendant() needs to happen
>> within in rcu section. On a preemptable kernel, let's say we got
>> preempted in between them, the flusher was unrelated and got freed
>> before we get the CPU. In that case we are accessing freed memory.
>>
> 
> I have to think about this some more.
> 

I don't think this is necessary. We are now waiting (for completion) and 
not skipping flush, because as part of take down function 
cgroup_rstat_exit() is called, which will call cgroup_rstat_flush().


  void cgroup_rstat_exit(struct cgroup *cgrp)
  {
	int cpu;
	cgroup_rstat_flush(cgrp);


>>> +            wait_for_completion_interruptible_timeout(
>>> +                &cgrp_ongoing->flush_done, MAX_WAIT);
>>> +
>>> +            return false;
>>> +        }
>>> +        __cgroup_rstat_lock(cgrp, -1, false);
>>> +    }
>>> +    /* Obtained lock, record this cgrp as the ongoing flusher */
>>> +    if (!READ_ONCE(cgrp_rstat_ongoing_flusher)) {

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

[Yosry Ahmed]

On Mon, Jul 8, 2024 at 8:26 AM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>
>
> On 28/06/2024 11.39, Jesper Dangaard Brouer wrote:
> >
> >
> > On 28/06/2024 01.34, Shakeel Butt wrote:
> >> On Thu, Jun 27, 2024 at 11:18:56PM 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.
> >>>
> [...]
> >>>   static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu);
> >>> @@ -312,6 +315,45 @@ static inline void __cgroup_rstat_unlock(struct
> >>> cgroup *cgrp, int cpu_in_loop)
> >>>       spin_unlock_irq(&cgroup_rstat_lock);
> >>>   }
> >>> +#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)
> >>> +{
> >>> +    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 && cgroup_is_descendant(cgrp, cgrp_ongoing)) {
> >>
> >> I wonder if READ_ONCE() and cgroup_is_descendant() needs to happen
> >> within in rcu section. On a preemptable kernel, let's say we got
> >> preempted in between them, the flusher was unrelated and got freed
> >> before we get the CPU. In that case we are accessing freed memory.
> >>
> >
> > I have to think about this some more.
> >
>
> I don't think this is necessary. We are now waiting (for completion) and
> not skipping flush, because as part of take down function
> cgroup_rstat_exit() is called, which will call cgroup_rstat_flush().
>
>
>   void cgroup_rstat_exit(struct cgroup *cgrp)
>   {
>         int cpu;
>         cgroup_rstat_flush(cgrp);
>
>

Sorry for the late response, I was traveling for a bit. I will take a
look at your most recent version shortly. But I do have a comment
here.

I don't see how this addresses Shakeel's concern. IIUC, if the cgroup
was freed after READ_ONCE() (and cgroup_rstat_flush() was called),
then cgroup_is_descendant() will access freed memory. We are not
holding the lock here so we are not preventing cgroup_rstat_flush()
from being called for the freed cgroup, right?

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

[Jesper Dangaard Brouer]

On 16/07/2024 23.54, Yosry Ahmed wrote:
> On Mon, Jul 8, 2024 at 8:26 AM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>>
>>
>> On 28/06/2024 11.39, Jesper Dangaard Brouer wrote:
>>>
>>>
>>> On 28/06/2024 01.34, Shakeel Butt wrote:
>>>> On Thu, Jun 27, 2024 at 11:18:56PM 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.
>>>>>
>> [...]
>>>>>    static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu);
>>>>> @@ -312,6 +315,45 @@ static inline void __cgroup_rstat_unlock(struct
>>>>> cgroup *cgrp, int cpu_in_loop)
>>>>>        spin_unlock_irq(&cgroup_rstat_lock);
>>>>>    }
>>>>> +#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)
>>>>> +{
>>>>> +    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 && cgroup_is_descendant(cgrp, cgrp_ongoing)) {
>>>>
>>>> I wonder if READ_ONCE() and cgroup_is_descendant() needs to happen
>>>> within in rcu section. On a preemptable kernel, let's say we got
>>>> preempted in between them, the flusher was unrelated and got freed
>>>> before we get the CPU. In that case we are accessing freed memory.
>>>>
>>>
>>> I have to think about this some more.
>>>
>>
>> I don't think this is necessary. We are now waiting (for completion) and
>> not skipping flush, because as part of take down function
>> cgroup_rstat_exit() is called, which will call cgroup_rstat_flush().
>>
>>
>>    void cgroup_rstat_exit(struct cgroup *cgrp)
>>    {
>>          int cpu;
>>          cgroup_rstat_flush(cgrp);
>>
>>
> 
> Sorry for the late response, I was traveling for a bit. I will take a
> look at your most recent version shortly. But I do have a comment
> here.
> 
> I don't see how this addresses Shakeel's concern. IIUC, if the cgroup
> was freed after READ_ONCE() (and cgroup_rstat_flush() was called),
> then cgroup_is_descendant() will access freed memory. We are not
> holding the lock here so we are not preventing cgroup_rstat_flush()
> from being called for the freed cgroup, right?

If we go back to only allowing root-cgroup to be ongoing-flusher, then
we could do a cgroup_rstat_flush(root) in cgroup_rstat_exit() to be sure
nothing is left waiting for completion scheme. Right?

IMHO the code is getting too complicated with sub-cgroup's as ongoing
flushers which also required having 'completion' queues per cgroup.
We should go back to only doing this for the root-cgroup.

--Jesper

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

[Yosry Ahmed]

On Wed, Jul 17, 2024 at 12:46 AM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>
>
>
> On 16/07/2024 23.54, Yosry Ahmed wrote:
> > On Mon, Jul 8, 2024 at 8:26 AM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
> >>
> >>
> >> On 28/06/2024 11.39, Jesper Dangaard Brouer wrote:
> >>>
> >>>
> >>> On 28/06/2024 01.34, Shakeel Butt wrote:
> >>>> On Thu, Jun 27, 2024 at 11:18:56PM 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.
> >>>>>
> >> [...]
> >>>>>    static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu);
> >>>>> @@ -312,6 +315,45 @@ static inline void __cgroup_rstat_unlock(struct
> >>>>> cgroup *cgrp, int cpu_in_loop)
> >>>>>        spin_unlock_irq(&cgroup_rstat_lock);
> >>>>>    }
> >>>>> +#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)
> >>>>> +{
> >>>>> +    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 && cgroup_is_descendant(cgrp, cgrp_ongoing)) {
> >>>>
> >>>> I wonder if READ_ONCE() and cgroup_is_descendant() needs to happen
> >>>> within in rcu section. On a preemptable kernel, let's say we got
> >>>> preempted in between them, the flusher was unrelated and got freed
> >>>> before we get the CPU. In that case we are accessing freed memory.
> >>>>
> >>>
> >>> I have to think about this some more.
> >>>
> >>
> >> I don't think this is necessary. We are now waiting (for completion) and
> >> not skipping flush, because as part of take down function
> >> cgroup_rstat_exit() is called, which will call cgroup_rstat_flush().
> >>
> >>
> >>    void cgroup_rstat_exit(struct cgroup *cgrp)
> >>    {
> >>          int cpu;
> >>          cgroup_rstat_flush(cgrp);
> >>
> >>
> >
> > Sorry for the late response, I was traveling for a bit. I will take a
> > look at your most recent version shortly. But I do have a comment
> > here.
> >
> > I don't see how this addresses Shakeel's concern. IIUC, if the cgroup
> > was freed after READ_ONCE() (and cgroup_rstat_flush() was called),
> > then cgroup_is_descendant() will access freed memory. We are not
> > holding the lock here so we are not preventing cgroup_rstat_flush()
> > from being called for the freed cgroup, right?
>
> If we go back to only allowing root-cgroup to be ongoing-flusher, then
> we could do a cgroup_rstat_flush(root) in cgroup_rstat_exit() to be sure
> nothing is left waiting for completion scheme. Right?

I am still not sure I understand how this helps.

We still need to call cgroup_is_descendant() because in cgroup v1 we
may have multiple root cgroups, right?

So it is still possible that the cgroup is freed after READ_ONCE() and
cgroup_is_descendant() accesses freed memory. Unless of course we have
other guarantees that the root cgroups will not go away.

Since at this point we are not holding the rstat lock, or actually
waiting for the ongoing flush (yet), I don't see how any
cgroup_rstat_flush() calls in the cgroup exit paths will help.

I actually think RCU may not help either for non-root cgroups, because
we call cgroup_rstat_flush() in cgroup_rstat_exit(), which is called
*after* the RCU grace period, and the cgroup is freed right away after
that. We may need to replace kfree(cgrp) with kfree_rcu(cgrp) in
css_free_rwork_fn().

>
> IMHO the code is getting too complicated with sub-cgroup's as ongoing
> flushers which also required having 'completion' queues per cgroup.
> We should go back to only doing this for the root-cgroup.

Because of multiple root cgroups in cgroup v1, we may still need that
anyway, right?

Please let me know if I am missing something.

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

[Waiman Long]

On 6/27/24 17:18, Jesper Dangaard Brouer wrote:
> 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);
>   }
>   
>
>
Will it be cleaner to add a "bool *flushed" output parameter to 
__cgroup_rstat_lock() so that the caller can respond differently whether 
the flushed flag is set or not? In that way, you don't need to expose a 
separate trylock() API. Also your commit log is empty.

Cheers,
Longman

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

[Waiman Long]

On 6/27/24 18:22, Waiman Long wrote:
>
> On 6/27/24 17:18, Jesper Dangaard Brouer wrote:
>> 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);
>>   }
>>
>>
> Will it be cleaner to add a "bool *flushed" output parameter to 
> __cgroup_rstat_lock() so that the caller can respond differently 
> whether the flushed flag is set or not? In that way, you don't need to 
> expose a separate trylock() API. Also your commit log is empty.

Looking at the use case in patch 2, I would suggest the following APIs.

- bool cgroup_rstat_lock(struct cgroup *cgrp)
- bool cgroup_rstat_lock_or_flushed(struct cgroup *cgrp)

Both will return a bool indicating a flush has already been done if 
true. The 2nd function will not take the lock if a flush is ongoing. 
Both will wait if a flush is ongoing.

Cheers,
Longman

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

[Jesper Dangaard Brouer]

On 28/06/2024 00.22, Waiman Long wrote:
> 
> On 6/27/24 17:18, Jesper Dangaard Brouer wrote:
[...]
>>
> Will it be cleaner to add a "bool *flushed" output parameter to 
> __cgroup_rstat_lock() so that the caller can respond differently whether 
> the flushed flag is set or not? In that way, you don't need to expose a 
> separate trylock() API. Also your commit log is empty.
> 

Dropping this API in V5 anyway.
But I do think it is more natural to follow the 'trylock' API as this is
something that people have seen before.

--Jesper