sched, timer: Use atomics for thread_group_cputimer to improve scalability

This patch converts the timers to 64 bit atomic variables and use atomic add to update them without a lock. With this patch, the percent of total time spent updating thread group cputimer timers was reduced from 30% down to less than 1%.

kernel/time/posix-cpu-timers.c +12 -6

-static void update_gt_cputime(struct task_cputime *a, struct task_cputime *b)
+static inline void __update_gt_cputime(atomic64_t *cputime, u64 sum_cputime)
 {
-	if (b->utime > a->utime)
-		a->utime = b->utime;
-
-	if (b->stime > a->stime)
-		a->stime = b->stime;
+	u64 curr_cputime;
+	/*
+	 * Set cputime to sum_cputime if sum_cputime > cputime. Use cmpxchg
+	 * to avoid race conditions with concurrent updates to cputime.
+	 */
+retry:
+	curr_cputime = atomic64_read(cputime);
+	if (sum_cputime > curr_cputime) {
+		if (atomic64_cmpxchg(cputime, curr_cputime, sum_cputime) != curr_cputime)
+			goto retry;
+	}

Well, I forgot everything about this code, but let me ask anyway ;)

Quoted 20 lines · Jason Low

kernel/time/posix-cpu-timers.c +12 -6

-static void update_gt_cputime(struct task_cputime *a, struct task_cputime *b)
+static inline void __update_gt_cputime(atomic64_t *cputime, u64 sum_cputime)
 {
-	if (b->utime > a->utime)
-		a->utime = b->utime;
-
-	if (b->stime > a->stime)
-		a->stime = b->stime;
+	u64 curr_cputime;
+	/*
+	 * Set cputime to sum_cputime if sum_cputime > cputime. Use cmpxchg
+	 * to avoid race conditions with concurrent updates to cputime.
+	 */
+retry:
+	curr_cputime = atomic64_read(cputime);
+	if (sum_cputime > curr_cputime) {
+		if (atomic64_cmpxchg(cputime, curr_cputime, sum_cputime) != curr_cputime)
+			goto retry;
+	}

kernel/time/posix-cpu-timers.c static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p, · line 227

Quoted 10 lines

kernel/time/posix-cpu-timers.c +6 -2

+}
 
-	if (b->sum_exec_runtime > a->sum_exec_runtime)
-		a->sum_exec_runtime = b->sum_exec_runtime;
+static void update_gt_cputime(struct thread_group_cputimer *cputimer, struct task_cputime *sum)
+{
+	__update_gt_cputime(&cputimer->utime, sum->utime);
+	__update_gt_cputime(&cputimer->stime, sum->stime);
+	__update_gt_cputime(&cputimer->sum_exec_runtime, sum->sum_exec_runtime);
 }

And this is called if !cputimer_running().

So who else can update these atomic64_t's ? The caller is called under ->siglock. IOW, do we really need to cmpxchg/retry ?

Just curious, I am sure I missed something.

Quoted 40 lines · Oleg Nesterov

Well, I forgot everything about this code, but let me ask anyway ;)

Quoted 20 lines · Jason Low

kernel/time/posix-cpu-timers.c +12 -6

-static void update_gt_cputime(struct task_cputime *a, struct task_cputime *b)
+static inline void __update_gt_cputime(atomic64_t *cputime, u64 sum_cputime)
 {
-	if (b->utime > a->utime)
-		a->utime = b->utime;
-
-	if (b->stime > a->stime)
-		a->stime = b->stime;
+	u64 curr_cputime;
+	/*
+	 * Set cputime to sum_cputime if sum_cputime > cputime. Use cmpxchg
+	 * to avoid race conditions with concurrent updates to cputime.
+	 */
+retry:
+	curr_cputime = atomic64_read(cputime);
+	if (sum_cputime > curr_cputime) {
+		if (atomic64_cmpxchg(cputime, curr_cputime, sum_cputime) != curr_cputime)
+			goto retry;
+	}

kernel/time/posix-cpu-timers.c static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p, · line 227

Quoted 10 lines

kernel/time/posix-cpu-timers.c +6 -2

+}
 
-	if (b->sum_exec_runtime > a->sum_exec_runtime)
-		a->sum_exec_runtime = b->sum_exec_runtime;
+static void update_gt_cputime(struct thread_group_cputimer *cputimer, struct task_cputime *sum)
+{
+	__update_gt_cputime(&cputimer->utime, sum->utime);
+	__update_gt_cputime(&cputimer->stime, sum->stime);
+	__update_gt_cputime(&cputimer->sum_exec_runtime, sum->sum_exec_runtime);
 }

And this is called if !cputimer_running().

So who else can update these atomic64_t's ? The caller is called under ->siglock. IOW, do we really need to cmpxchg/retry ?

Quoted 1 line

Just curious, I am sure I missed something.

Ah, sorry, I seem to understand.

We still can race with account_group_*time() even if ->running == 0. Because (say) account_group_exec_runtime() can race with 1 -> 0 -> 1 transition.

Or is there another reason?

Well, I forgot everything about this code, but let me ask anyway ;)

On 03/02, Jason Low wrote:

kernel/time/posix-cpu-timers.c void thread_group_cputimer(struct task_struct *tsk, struct task_cputime *times) · line 243

Quoted 13 lines

kernel/time/posix-cpu-timers.c +2 -7

@@ -222,13 +239,10 @@ void thread_group_cputimer(struct task_struct *tsk, struct task_cputime *times)
 		 * it.
 		 */
 		thread_group_cputime(tsk, &sum);
-		raw_spin_lock_irqsave(&cputimer->lock, flags);
-		cputimer->running = 1;
-		update_gt_cputime(&cputimer->cputime, &sum);
-	} else
-		raw_spin_lock_irqsave(&cputimer->lock, flags);
-	*times = cputimer->cputime;
-	raw_spin_unlock_irqrestore(&cputimer->lock, flags);
+		update_gt_cputime(cputimer, &sum);
+		ACCESS_ONCE(cputimer->running) = 1;

WRITE_ONCE() looks better...

but it is not clear to me why do we need it
at all.

In original code, we set cputimer->running first so it is running while we call update_gt_cputime(). Now in this patch, we swapped the 2 calls such that we set running after calling update_gt_cputime(), so that wouldn't be an issue anymore.

Quoted 5 lines · Jason Low

This patch converts the timers to 64 bit atomic variables and use atomic add to update them without a lock. With this patch, the percent of total time spent updating thread group cputimer timers was reduced from 30% down to less than 1%.

NAK.

Not because I think this is wrong, but because somebody needs to look at the effects on 32-bit architectures too.

In particular, check out lib/atomic64.c - which uses a hashed array of 16-bit spinlocks to do 64-bit atomics. That may or may well work ok in practice, but it does mean that now sample_group_cputimer() and update_gt_cputime() will take that (it ends up generally being the same) spinlock three times for the three atomic64_read()'s.

Quoted 5 lines · Jason Low

In original code, we set cputimer->running first so it is running while we call update_gt_cputime(). Now in this patch, we swapped the 2 calls such that we set running after calling update_gt_cputime(), so that wouldn't be an issue anymore.

Hmm. If you actually care about ordering, and 'running' should be written to after the other things, then it might be best if you use

   smp_store_release(&cputimer->running, 1);

which makes it clear that the store happens *after* what went before it.

Or at least have a "smp_wmb()" between the atomic64 updates and the "WRITE_ONCE()".

I guess that since you use cmpxchg in update_gt_cputime, the accesses end up being ordered anyway, but it might be better to make that thing very explicit.

Quoted 5 lines · Jason Low

In original code, we set cputimer->running first so it is running while we call update_gt_cputime(). Now in this patch, we swapped the 2 calls such that we set running after calling update_gt_cputime(), so that wouldn't be an issue anymore.

Hmm. If you actually care about ordering, and 'running' should be written to after the other things, then it might be best if you use

   smp_store_release(&cputimer->running, 1);

which makes it clear that the store happens *after* what went before it.

Or at least have a "smp_wmb()" between the atomic64 updates and the "WRITE_ONCE()".

I guess that since you use cmpxchg in update_gt_cputime, the accesses end up being ordered anyway, but it might be better to make that thing very explicit.

Linus

v1->v2:
- Peter suggested that cputimer->running does not need to be atomic, so we can leave it as an integer.
- Address a race condition that could occur in update_gt_cputime().
- Add helper functions to avoid repeating code.

While running a database workload, we found a scalability issue with itimers.

Much of the problem was caused by the thread_group_cputimer spinlock. Each time we account for group system/user time, we need to obtain a thread_group_cputimer's spinlock to update the timers. On larger systems (such as a 16 socket machine), this caused more than 30% of total time spent trying to obtain this kernel lock to update these group timer stats.

This patch converts the timers to 64 bit atomic variables and use atomic add to update them without a lock. With this patch, the percent of total time spent updating thread group cputimer timers was reduced from 30% down to less than 1%.

Signed-off-by Jason Low <[email protected]>

---
 include/linux/init_task.h      |    7 +++--
 include/linux/sched.h          |   10 ++-----
 kernel/fork.c                  |    3 --
 kernel/sched/stats.h           |   12 ++------
 kernel/time/posix-cpu-timers.c |   55 +++++++++++++++++++++++----------------
 5 files changed, 42 insertions(+), 45 deletions(-)

include/linux/init_task.h +4 -3

index 3037fc0..c4cdec7 100644
@@ -50,9 +50,10 @@ extern struct fs_struct init_fs;
 	.cpu_timers	= INIT_CPU_TIMERS(sig.cpu_timers),		\
 	.rlim		= INIT_RLIMITS,					\
 	.cputimer	= { 						\
-		.cputime = INIT_CPUTIME,				\
-		.running = 0,						\
-		.lock = __RAW_SPIN_LOCK_UNLOCKED(sig.cputimer.lock),	\
+		.utime = ATOMIC64_INIT(0),                              \
+		.stime = ATOMIC64_INIT(0),                              \
+		.sum_exec_runtime = ATOMIC64_INIT(0),                   \
+		.running = 0						\
 	},								\
 	.cred_guard_mutex =						\
 		 __MUTEX_INITIALIZER(sig.cred_guard_mutex),		\

include/linux/sched.h +3 -7

index 8db31ef..d6b0f76 100644
@@ -588,9 +588,10 @@ struct task_cputime {
  * used for thread group CPU timer calculations.
  */
 struct thread_group_cputimer {
-	struct task_cputime cputime;
+	atomic64_t utime;
+	atomic64_t stime;
+	atomic64_t sum_exec_runtime;
 	int running;
-	raw_spinlock_t lock;
 };
 
 #include <linux/rwsem.h>

@@ -2942,11 +2943,6 @@ static __always_inline bool need_resched(void)
 void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times);
 void thread_group_cputimer(struct task_struct *tsk, struct task_cputime *times);
 
-static inline void thread_group_cputime_init(struct signal_struct *sig)
-{
-	raw_spin_lock_init(&sig->cputimer.lock);
-}
-
 /*
  * Reevaluate whether the task has signals pending delivery.
  * Wake the task if so.

kernel/fork.c +0 -3

index 4dc2dda..df9dfe9 100644
@@ -1037,9 +1037,6 @@ static void posix_cpu_timers_init_group(struct signal_struct *sig)
 {
 	unsigned long cpu_limit;
 
-	/* Thread group counters. */
-	thread_group_cputime_init(sig);
-
 	cpu_limit = ACCESS_ONCE(sig->rlim[RLIMIT_CPU].rlim_cur);
 	if (cpu_limit != RLIM_INFINITY) {
 		sig->cputime_expires.prof_exp = secs_to_cputime(cpu_limit);

kernel/sched/stats.h +3 -9

index 4ab7043..adda94e 100644
@@ -215,9 +215,7 @@ static inline void account_group_user_time(struct task_struct *tsk,
 	if (!cputimer_running(tsk))
 		return;
 
-	raw_spin_lock(&cputimer->lock);
-	cputimer->cputime.utime += cputime;
-	raw_spin_unlock(&cputimer->lock);
+	atomic64_add(cputime, &cputimer->utime);
 }
 
 /**

@@ -238,9 +236,7 @@ static inline void account_group_system_time(struct task_struct *tsk,
 	if (!cputimer_running(tsk))
 		return;
 
-	raw_spin_lock(&cputimer->lock);
-	cputimer->cputime.stime += cputime;
-	raw_spin_unlock(&cputimer->lock);
+	atomic64_add(cputime, &cputimer->stime);
 }
 
 /**

@@ -261,7 +257,5 @@ static inline void account_group_exec_runtime(struct task_struct *tsk,
 	if (!cputimer_running(tsk))
 		return;
 
-	raw_spin_lock(&cputimer->lock);
-	cputimer->cputime.sum_exec_runtime += ns;
-	raw_spin_unlock(&cputimer->lock);
+	atomic64_add(ns, &cputimer->sum_exec_runtime);
 }

kernel/time/posix-cpu-timers.c +0 -0

index a16b678..ba93c23 100644

Quoted 131 lines · Jason Low

v1->v2:
- Peter suggested that cputimer->running does not need to be atomic, so we can leave it as an integer.
- Address a race condition that could occur in update_gt_cputime().
- Add helper functions to avoid repeating code.

While running a database workload, we found a scalability issue with itimers.

Much of the problem was caused by the thread_group_cputimer spinlock. Each time we account for group system/user time, we need to obtain a thread_group_cputimer's spinlock to update the timers. On larger systems (such as a 16 socket machine), this caused more than 30% of total time spent trying to obtain this kernel lock to update these group timer stats.

This patch converts the timers to 64 bit atomic variables and use atomic add to update them without a lock. With this patch, the percent of total time spent updating thread group cputimer timers was reduced from 30% down to less than 1%.

Signed-off-by Jason Low <[email protected]>

---
 include/linux/init_task.h      |    7 +++--
 include/linux/sched.h          |   10 ++-----
 kernel/fork.c                  |    3 --
 kernel/sched/stats.h           |   12 ++------
 kernel/time/posix-cpu-timers.c |   55 +++++++++++++++++++++++----------------
 5 files changed, 42 insertions(+), 45 deletions(-)

include/linux/init_task.h +4 -3

index 3037fc0..c4cdec7 100644
@@ -50,9 +50,10 @@ extern struct fs_struct init_fs;
 	.cpu_timers	= INIT_CPU_TIMERS(sig.cpu_timers),		\
 	.rlim		= INIT_RLIMITS,					\
 	.cputimer	= { 						\
-		.cputime = INIT_CPUTIME,				\
-		.running = 0,						\
-		.lock = __RAW_SPIN_LOCK_UNLOCKED(sig.cputimer.lock),	\
+		.utime = ATOMIC64_INIT(0),                              \
+		.stime = ATOMIC64_INIT(0),                              \
+		.sum_exec_runtime = ATOMIC64_INIT(0),                   \
+		.running = 0						\
 	},								\
 	.cred_guard_mutex =						\
 		 __MUTEX_INITIALIZER(sig.cred_guard_mutex),		\

include/linux/sched.h +3 -7

index 8db31ef..d6b0f76 100644
@@ -588,9 +588,10 @@ struct task_cputime {
  * used for thread group CPU timer calculations.
  */
 struct thread_group_cputimer {
-	struct task_cputime cputime;
+	atomic64_t utime;
+	atomic64_t stime;
+	atomic64_t sum_exec_runtime;
 	int running;
-	raw_spinlock_t lock;
 };
 
 #include <linux/rwsem.h>

@@ -2942,11 +2943,6 @@ static __always_inline bool need_resched(void)
 void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times);
 void thread_group_cputimer(struct task_struct *tsk, struct task_cputime *times);
 
-static inline void thread_group_cputime_init(struct signal_struct *sig)
-{
-	raw_spin_lock_init(&sig->cputimer.lock);
-}
-
 /*
  * Reevaluate whether the task has signals pending delivery.
  * Wake the task if so.

kernel/fork.c +0 -3

index 4dc2dda..df9dfe9 100644
@@ -1037,9 +1037,6 @@ static void posix_cpu_timers_init_group(struct signal_struct *sig)
 {
 	unsigned long cpu_limit;
 
-	/* Thread group counters. */
-	thread_group_cputime_init(sig);
-
 	cpu_limit = ACCESS_ONCE(sig->rlim[RLIMIT_CPU].rlim_cur);
 	if (cpu_limit != RLIM_INFINITY) {
 		sig->cputime_expires.prof_exp = secs_to_cputime(cpu_limit);

kernel/sched/stats.h +3 -9

index 4ab7043..adda94e 100644
@@ -215,9 +215,7 @@ static inline void account_group_user_time(struct task_struct *tsk,
 	if (!cputimer_running(tsk))
 		return;
 
-	raw_spin_lock(&cputimer->lock);
-	cputimer->cputime.utime += cputime;
-	raw_spin_unlock(&cputimer->lock);
+	atomic64_add(cputime, &cputimer->utime);
 }
 
 /**

@@ -238,9 +236,7 @@ static inline void account_group_system_time(struct task_struct *tsk,
 	if (!cputimer_running(tsk))
 		return;
 
-	raw_spin_lock(&cputimer->lock);
-	cputimer->cputime.stime += cputime;
-	raw_spin_unlock(&cputimer->lock);
+	atomic64_add(cputime, &cputimer->stime);
 }
 
 /**

@@ -261,7 +257,5 @@ static inline void account_group_exec_runtime(struct task_struct *tsk,
 	if (!cputimer_running(tsk))
 		return;
 
-	raw_spin_lock(&cputimer->lock);
-	cputimer->cputime.sum_exec_runtime += ns;
-	raw_spin_unlock(&cputimer->lock);
+	atomic64_add(ns, &cputimer->sum_exec_runtime);
 }

kernel/time/posix-cpu-timers.c +0 -0

index a16b678..ba93c23 100644

kernel/time/posix-cpu-timers.c posix_cpu_clock_set(const clockid_t which_clock, const struct timespec *tp) · line 182

Quoted 10 lines

kernel/time/posix-cpu-timers.c +7 -0

@@ -173,6 +173,14 @@ posix_cpu_clock_set(const clockid_t which_clock, const struct timespec *tp)
 	return error;
 }
 
+/* Sample thread_group_cputimer values in "cputimer", copy results to "times" */
+static inline void sample_group_cputimer(struct task_cputime *times,
+			                 struct thread_group_cputimer *cputimer)
+{
+        times->utime = atomic64_read(&cputimer->utime);
+        times->stime = atomic64_read(&cputimer->stime);
+        times->sum_exec_runtime = atomic64_read(&cputimer->sum_exec_runtime);

So, in the case we are calling that right after setting cputimer->running, I guess we are fine because we just updated cputimer with the freshest values.

But if we are reading this a while after, say several ticks further, there is a chance that we read stale values since we don't lock anymore.

I don't know if it matters or not, I guess it depends how stale it can be and how much precision we expect from posix cpu timers. It probably doesn't matter.

But just in case, atomic64_read_return(&cputimer->utime, 0) would make sure we get the freshest value because it performs a full barrier, at the cost of more overhead of course.

Quoted 6 lines · Frederic Weisbecker

So, in the case we are calling that right after setting cputimer->running, I guess we are fine because we just updated cputimer with the freshest values.

But if we are reading this a while after, say several ticks further, there is a chance that we read stale values since we don't lock anymore.

Quoted 5 lines

I don't know if it matters or not, I guess it depends how stale it can be and how much precision we expect from posix cpu timers. It probably doesn't matter.

But just in case, atomic64_read_return(&cputimer->utime, 0) would make sure we get the freshest value because it performs a full barrier, at the cost of more overhead of course.

Well, if we are running within a guest OS, we might be delayed at any point for quite some time. Even with interrupts disabled.

Quoted 10 lines · Paul E. McKenney

Quoted 9 lines · Frederic Weisbecker

So, in the case we are calling that right after setting cputimer->running, I guess we are fine because we just updated cputimer with the freshest values.

But if we are reading this a while after, say several ticks further, there is a chance that we read stale values since we don't lock anymore.

I don't know if it matters or not, I guess it depends how stale it can be and how much precision we expect from posix cpu timers. It probably doesn't matter.

Quoted 5 lines

Quoted 2 lines

But just in case, atomic64_read_return(&cputimer->utime, 0) would make sure we get the freshest value because it performs a full barrier, at the cost of more overhead of course.

Well, if we are running within a guest OS, we might be delayed at any point for quite some time. Even with interrupts disabled.

You mean delayed because of the overhead of atomic_add_return() or the stale value of cptimer-> fields?

Quoted 12 lines · Linus Torvalds

Quoted 5 lines · Jason Low

In original code, we set cputimer->running first so it is running while we call update_gt_cputime(). Now in this patch, we swapped the 2 calls such that we set running after calling update_gt_cputime(), so that wouldn't be an issue anymore.

Hmm. If you actually care about ordering, and 'running' should be written to after the other things, then it might be best if you use

   smp_store_release(&cputimer->running, 1);

Quoted 4 lines

which makes it clear that the store happens *after* what went before it.

Or at least have a "smp_wmb()" between the atomic64 updates and the "WRITE_ONCE()".

FWIW, perhaps it can be reduced with an smp_mb__before_atomic() on the account_group_*_time() side,

paired with smp_wmb() from the thread_group_cputimer()
side. Arming cputime->running shouldn't be too frequent while update cputime happens at least every tick...

Assuming smp_mb__before_atomic() is more lightweight than smp_load_acquire() of course.

Quoted 6 lines

I guess that since you use cmpxchg in update_gt_cputime, the accesses end up being ordered anyway, but it might be better to make that thing very explicit.

Linus

kernel/time/posix-cpu-timers.c posix_cpu_clock_set(const clockid_t which_clock, const struct timespec *tp) · line 182

Quoted 7 lines · Jason Low

kernel/time/posix-cpu-timers.c +7 -0

+/* Sample thread_group_cputimer values in "cputimer", copy results to "times" */
+static inline void sample_group_cputimer(struct task_cputime *times,
+			                 struct thread_group_cputimer *cputimer)
+{
+        times->utime = atomic64_read(&cputimer->utime);
+        times->stime = atomic64_read(&cputimer->stime);
+        times->sum_exec_runtime = atomic64_read(&cputimer->sum_exec_runtime);

So, in the case we are calling that right after setting cputimer->running, I guess we are fine because we just updated cputimer with the freshest values.

But if we are reading this a while after, say several ticks further, there is a chance that we read stale values since we don't lock anymore.

I don't know if it matters or not, I guess it depends how stale it can be and how much precision we expect from posix cpu timers. It probably doesn't matter.

But just in case, atomic64_read_return(&cputimer->utime, 0) would make sure we get the freshest value because it performs a full barrier, at the cost of more overhead of course.

Quoted 7 lines · Linus Torvalds

Quoted 5 lines · Jason Low

This patch converts the timers to 64 bit atomic variables and use atomic add to update them without a lock. With this patch, the percent of total time spent updating thread group cputimer timers was reduced from 30% down to less than 1%.

Quoted 4 lines

NAK.

Not because I think this is wrong, but because somebody needs to look at the effects on 32-bit architectures too.

Okay, I will run some tests to see how this change affects the performance of itimers on 32 bit systems.

I tested this patch on a 32 bit ARM system with 4 cores. Using the generic 64 bit atomics, I did not see any performance change with this patch, and the relevant functions (account_group_*_time(), ect...) don't show up in perf reports.

One factor might be because locking/cacheline contention isn't as apparent on smaller systems to begin with, and lib/atomic64.c also mentions that "this is expected to used on systems with small numbers of CPUs (<= 4 or so)".

Quoted 5 lines · Jason Low

I tested this patch on a 32 bit ARM system with 4 cores. Using the generic 64 bit atomics, I did not see any performance change with this patch, and the relevant functions (account_group_*_time(), ect...) don't show up in perf reports.

Ok.

Quoted 4 lines

One factor might be because locking/cacheline contention isn't as apparent on smaller systems to begin with, and lib/atomic64.c also mentions that "this is expected to used on systems with small numbers of CPUs (<= 4 or so)".

Yeah, that's probably a valid argument anyway - 32-bit systems aren't really going to be multi-node big systems any more.

So I'm ok with the patch,