timers: framework for migration between CPU

kernel/timer.c static inline void timer_set_deferrable( · line 123

Quoted 6 lines · Arun R Bharadwaj

kernel/timer.c +5 -0

+static inline unsigned long tbase_get_flag_bits(struct timer_list *timer)
+{
+	return tbase_get_deferrable(timer->base) |
+				tbase_get_pinned(timer->base);
+}

I'd say this looks a bit strange. Hopefully compiler can optimize this code to return (unsigned long)base & (TBASE_DEFERRABLE_FLAG | TBASE_PINNED_FLAG).

Quoted 4 lines

kernel/timer.c +0 -0

@@ -736,6 +759,7 @@ void add_timer_on(struct timer_list *tim
 	struct tvec_base *base = per_cpu(tvec_bases, cpu);
 	unsigned long flags;
 

kernel/timer.c void add_timer_on(struct timer_list *tim · line 762

Quoted 1 line

kernel/timer.c +1 -0

+	timer_set_pinned(timer);

But we never clear TBASE_PINNED_FLAG?

If we use mod_timer() next time, the timer remains "pinned". I do not say this is really wrong, but a bit strange imho.

Oleg.

kernel/timer.c static inline void timer_set_deferrable( · line 123

Quoted 6 lines · Arun R Bharadwaj

kernel/timer.c +5 -0

+static inline unsigned long tbase_get_flag_bits(struct timer_list *timer)
+{
+	return tbase_get_deferrable(timer->base) |
+				tbase_get_pinned(timer->base);
+}

I'd say this looks a bit strange. Hopefully compiler can optimize this code to return (unsigned long)base & (TBASE_DEFERRABLE_FLAG | TBASE_PINNED_FLAG).

Quoted 4 lines

kernel/timer.c +0 -0

@@ -736,6 +759,7 @@ void add_timer_on(struct timer_list *tim
 	struct tvec_base *base = per_cpu(tvec_bases, cpu);
 	unsigned long flags;
 

kernel/timer.c void add_timer_on(struct timer_list *tim · line 762

Quoted 1 line

kernel/timer.c +1 -0

+	timer_set_pinned(timer);

But we never clear TBASE_PINNED_FLAG?

If we use mod_timer() next time, the timer remains "pinned". I do not say this is really wrong, but a bit strange imho.

Oleg.

Quoted 8 lines · Oleg Nesterov

kernel/timer.c void add_timer_on(struct timer_list *tim · line 762

Quoted 5 lines

kernel/timer.c +1 -0

@@ -736,6 +759,7 @@ void add_timer_on(struct timer_list *tim
 	struct tvec_base *base = per_cpu(tvec_bases, cpu);
 	unsigned long flags;
 
+	timer_set_pinned(timer);

But we never clear TBASE_PINNED_FLAG?

Quoted 5 lines

If we use mod_timer() next time, the timer remains "pinned". I do not say this is really wrong, but a bit strange imho.

Oleg.

The pinned timer would expect to continue firing on the same CPU although it does a mod_timer() the next time, right?

Thats why I have not cleared the TBASE_PINNED_FLAG.

Quoted 8 lines · Oleg Nesterov

kernel/timer.c void add_timer_on(struct timer_list *tim · line 762

Quoted 5 lines

kernel/timer.c +1 -0

@@ -736,6 +759,7 @@ void add_timer_on(struct timer_list *tim
 	struct tvec_base *base = per_cpu(tvec_bases, cpu);
 	unsigned long flags;
 
+	timer_set_pinned(timer);

But we never clear TBASE_PINNED_FLAG?

Quoted 5 lines

If we use mod_timer() next time, the timer remains "pinned". I do not say this is really wrong, but a bit strange imho.

Oleg.

The pinned timer would expect to continue firing on the same CPU although it does a mod_timer() the next time, right?

Thats why I have not cleared the TBASE_PINNED_FLAG.

kernel/timer.c static inline void timer_set_deferrable( · line 123

Quoted 6 lines · Arun R Bharadwaj

kernel/timer.c +5 -0

+static inline unsigned long tbase_get_flag_bits(struct timer_list *timer)
+{
+	return tbase_get_deferrable(timer->base) |
+				tbase_get_pinned(timer->base);
+}

I'd say this looks a bit strange. Hopefully compiler can optimize this code to return (unsigned long)base & (TBASE_DEFERRABLE_FLAG | TBASE_PINNED_FLAG).

kernel/timer.c void add_timer_on(struct timer_list *tim · line 762

Quoted 5 lines

kernel/timer.c +1 -0

@@ -736,6 +759,7 @@ void add_timer_on(struct timer_list *tim
 	struct tvec_base *base = per_cpu(tvec_bases, cpu);
 	unsigned long flags;
 
+	timer_set_pinned(timer);

But we never clear TBASE_PINNED_FLAG?

If we use mod_timer() next time, the timer remains "pinned". I do not say this is really wrong, but a bit strange imho.

Oleg.

kernel/timer.c static inline void timer_set_deferrable( · line 123

Quoted 6 lines · Arun R Bharadwaj

kernel/timer.c +5 -0

+static inline unsigned long tbase_get_flag_bits(struct timer_list *timer)
+{
+	return tbase_get_deferrable(timer->base) |
+				tbase_get_pinned(timer->base);
+}

I'd say this looks a bit strange. Hopefully compiler can optimize this code to return (unsigned long)base & (TBASE_DEFERRABLE_FLAG | TBASE_PINNED_FLAG).

kernel/timer.c void add_timer_on(struct timer_list *tim · line 762

Quoted 5 lines

kernel/timer.c +1 -0

@@ -736,6 +759,7 @@ void add_timer_on(struct timer_list *tim
 	struct tvec_base *base = per_cpu(tvec_bases, cpu);
 	unsigned long flags;
 
+	timer_set_pinned(timer);

But we never clear TBASE_PINNED_FLAG?

If we use mod_timer() next time, the timer remains "pinned". I do not say this is really wrong, but a bit strange imho.

Oleg.

kernel/timer.c +3 -0

@@ -649,6 +650,16 @@ __mod_timer(struct timer_list *timer, un
 
        new_base = __get_cpu_var(tvec_bases);
 
+       current_cpu = smp_processor_id();
+       preferred_cpu = get_nohz_load_balancer();
+       if (enable_timer_migration && !tbase_get_pinned(timer->base)

&&
+ idle_cpu(current_cpu) && preferred_cpu != -1)
{

kernel/timer.c +3 -0

@@ -649,6 +650,16 @@ __mod_timer(struct timer_list *timer, un
 
        new_base = __get_cpu_var(tvec_bases);
 
+       current_cpu = smp_processor_id();
+       preferred_cpu = get_nohz_load_balancer();
+       if (enable_timer_migration && !tbase_get_pinned(timer->base)

&&
+ idle_cpu(current_cpu) && preferred_cpu != -1)
{

Quoted 10 lines · Arun R Bharadwaj

kernel/timer.c +3 -0

@@ -649,6 +650,16 @@ __mod_timer(struct timer_list *timer, un
 
        new_base = __get_cpu_var(tvec_bases);
 
+       current_cpu = smp_processor_id();
+       preferred_cpu = get_nohz_load_balancer();
+       if (enable_timer_migration && !tbase_get_pinned(timer->base)

&&
+ idle_cpu(current_cpu) && preferred_cpu != -1)
{

kernel/timer.c __mod_timer(struct timer_list *timer, un · line 662

Quoted 6 lines

kernel/timer.c +6 -0

+               new_base = per_cpu(tvec_bases, preferred_cpu);
+               timer_set_base(timer, new_base);
+               timer->expires = expires;
+               internal_add_timer(new_base, timer);
+               goto out_unlock;
+       }

Are you sure this compiles w/ CONFIG_SMP=n ? It looks like enable_timer_migration wouldn't exist in that case, but the chunks your adding in the timer code are still using it.

Daniel

Quoted 10 lines · Arun R Bharadwaj

kernel/timer.c +3 -0

@@ -649,6 +650,16 @@ __mod_timer(struct timer_list *timer, un
 
        new_base = __get_cpu_var(tvec_bases);
 
+       current_cpu = smp_processor_id();
+       preferred_cpu = get_nohz_load_balancer();
+       if (enable_timer_migration && !tbase_get_pinned(timer->base)

&&
+ idle_cpu(current_cpu) && preferred_cpu != -1)
{

kernel/timer.c __mod_timer(struct timer_list *timer, un · line 662

Quoted 6 lines

kernel/timer.c +6 -0

+               new_base = per_cpu(tvec_bases, preferred_cpu);
+               timer_set_base(timer, new_base);
+               timer->expires = expires;
+               internal_add_timer(new_base, timer);
+               goto out_unlock;
+       }

Are you sure this compiles w/ CONFIG_SMP=n ? It looks like enable_timer_migration wouldn't exist in that case, but the chunks your adding in the timer code are still using it.

Daniel

kernel/timer.c +1 -1

@@ -628,7 +629,7 @@ __mod_timer(struct timer_list *timer, un
 {
 	struct tvec_base *base, *new_base;
 	unsigned long flags;
-	int ret;
+	int ret, current_cpu, preferred_cpu;
 
 	ret = 0;
 

@@ -649,6 +650,16 @@ __mod_timer(struct timer_list *timer, un
 
 	new_base = __get_cpu_var(tvec_bases);

kernel/timer.c +1 -1

@@ -628,7 +629,7 @@ __mod_timer(struct timer_list *timer, un
 {
 	struct tvec_base *base, *new_base;
 	unsigned long flags;
-	int ret;
+	int ret, current_cpu, preferred_cpu;
 
 	ret = 0;
 

@@ -649,6 +650,16 @@ __mod_timer(struct timer_list *timer, un
 
 	new_base = __get_cpu_var(tvec_bases);

kernel/sched.c static struct { · line 4012

Quoted 7 lines · Arun R Bharadwaj

+++ linux.trees.git/kernel/sched.c

kernel/sched.c +1 -0

@@ -4009,6 +4009,11 @@ static struct {
 	.load_balancer = ATOMIC_INIT(-1),
 };
 
+inline int get_nohz_load_balancer(void)

inline?

kernel/sched.c static struct { · line 4015

Quoted 3 lines

kernel/sched.c +3 -0

+{
+	return atomic_read(&nohz.load_balancer);
+}

Shouldn't we reset .load_balancer when this CPU is CPU_DOWN'ed ? Otherwise the timer can migrate to the dead CPU.

Oleg.

kernel/sched.c static struct { · line 4012

Quoted 7 lines · Arun R Bharadwaj

+++ linux.trees.git/kernel/sched.c

kernel/sched.c +1 -0

@@ -4009,6 +4009,11 @@ static struct {
 	.load_balancer = ATOMIC_INIT(-1),
 };
 
+inline int get_nohz_load_balancer(void)

inline?

kernel/sched.c static struct { · line 4015

Quoted 3 lines

kernel/sched.c +3 -0

+{
+	return atomic_read(&nohz.load_balancer);
+}

Shouldn't we reset .load_balancer when this CPU is CPU_DOWN'ed ? Otherwise the timer can migrate to the dead CPU.

Oleg.

Quoted 11 lines · Oleg Nesterov

kernel/sched.c static struct { · line 4012

Quoted 7 lines · Arun R Bharadwaj

+++ linux.trees.git/kernel/sched.c

kernel/sched.c +1 -0

@@ -4009,6 +4009,11 @@ static struct {
 	.load_balancer = ATOMIC_INIT(-1),
 };
 
+inline int get_nohz_load_balancer(void)

inline?

Quoted 6 lines

kernel/sched.c static struct { · line 4015

Quoted 3 lines

kernel/sched.c +3 -0

+{
+	return atomic_read(&nohz.load_balancer);
+}

Shouldn't we reset .load_balancer when this CPU is CPU_DOWN'ed ? Otherwise the timer can migrate to the dead CPU.

In the select_nohz_load_balancer() code, we check if this CPU is in the cpu_active_map. If no, then this CPU relinquishes being the idle load balancer.

Also, the timer migration code in the CPU down path would migrate any timers queued onto this CPU, right ?

Quoted 11 lines · Oleg Nesterov

kernel/sched.c static struct { · line 4012

Quoted 7 lines · Arun R Bharadwaj

+++ linux.trees.git/kernel/sched.c

kernel/sched.c +1 -0

@@ -4009,6 +4009,11 @@ static struct {
 	.load_balancer = ATOMIC_INIT(-1),
 };
 
+inline int get_nohz_load_balancer(void)

inline?

Quoted 6 lines

kernel/sched.c static struct { · line 4015

Quoted 3 lines

kernel/sched.c +3 -0

+{
+	return atomic_read(&nohz.load_balancer);
+}

Shouldn't we reset .load_balancer when this CPU is CPU_DOWN'ed ? Otherwise the timer can migrate to the dead CPU.

In the select_nohz_load_balancer() code, we check if this CPU is in the cpu_active_map. If no, then this CPU relinquishes being the idle load balancer.

Also, the timer migration code in the CPU down path would migrate any timers queued onto this CPU, right ?

Quoted 20 lines · Gautham R Shenoy

Quoted 17 lines · Oleg Nesterov

kernel/sched.c static struct { · line 4012

Quoted 7 lines · Arun R Bharadwaj

+++ linux.trees.git/kernel/sched.c

kernel/sched.c +1 -0

@@ -4009,6 +4009,11 @@ static struct {
 	.load_balancer = ATOMIC_INIT(-1),
 };
 
+inline int get_nohz_load_balancer(void)

inline?

kernel/sched.c static struct { · line 4015

Quoted 3 lines

kernel/sched.c +3 -0

+{
+	return atomic_read(&nohz.load_balancer);
+}

Shouldn't we reset .load_balancer when this CPU is CPU_DOWN'ed ? Otherwise the timer can migrate to the dead CPU.

Quoted 3 lines

In the select_nohz_load_balancer() code, we check if this CPU is in the cpu_active_map. If no, then this CPU relinquishes being the idle load balancer.

I don't understand this code, but I am not sure select_nohz_load_balancer() is always called on cpu_down() path before migrate_timers/migrate_hrtimers.

If this is true, then there is no problem.

Quoted 2 lines

Also, the timer migration code in the CPU down path would migrate any timers queued onto this CPU, right ?

Yes, but if .load_balancer is not cleared before the timer migration, mod_timer() can move the timer to the dead CPU after migration.

Oleg.

Quoted 20 lines · Gautham R Shenoy

Quoted 17 lines · Oleg Nesterov

kernel/sched.c static struct { · line 4012

Quoted 7 lines · Arun R Bharadwaj

+++ linux.trees.git/kernel/sched.c

kernel/sched.c +1 -0

@@ -4009,6 +4009,11 @@ static struct {
 	.load_balancer = ATOMIC_INIT(-1),
 };
 
+inline int get_nohz_load_balancer(void)

inline?

kernel/sched.c static struct { · line 4015

Quoted 3 lines

kernel/sched.c +3 -0

+{
+	return atomic_read(&nohz.load_balancer);
+}

Shouldn't we reset .load_balancer when this CPU is CPU_DOWN'ed ? Otherwise the timer can migrate to the dead CPU.

Quoted 3 lines

In the select_nohz_load_balancer() code, we check if this CPU is in the cpu_active_map. If no, then this CPU relinquishes being the idle load balancer.

I don't understand this code, but I am not sure select_nohz_load_balancer() is always called on cpu_down() path before migrate_timers/migrate_hrtimers.

If this is true, then there is no problem.

Quoted 2 lines

Also, the timer migration code in the CPU down path would migrate any timers queued onto this CPU, right ?

Yes, but if .load_balancer is not cleared before the timer migration, mod_timer() can move the timer to the dead CPU after migration.

Oleg.

.load_balancer is the idle load balancer CPU which performs load balancing on behalf of all the idle cpus in the system. It's the only idle CPU which doesn't turn off it's ticks.

This CPU relinquishes it's role as the idle load balancer when
a) it finds a runnable task in it's runqueue, i.e before exiting idle state.
OR
b) all the CPUs in the system go idle.

Since it doesn't turn off it's ticks, it calls select_nohz_load_balancer() every scheduler tick, and thus can observe that it's no longer set in cpu_active_map within a tick or two.

Also, the cpu_down() path calls migrate_timers() in CPU_DEAD:,i.e after the CPU has gone down. But to take the CPU down, we would have invoked the stop_machine_run() code on that CPU, which by itself would make the CPU relinquish it's role as the idle load balancer owing to condition (a).

Thus I believe, mod_timer() can never migrate a timer on to a DEAD CPU, during/_after_ we invoke migrate_timers() from the CPU_DEAD callpath.

.load_balancer is the idle load balancer CPU which performs load balancing on behalf of all the idle cpus in the system. It's the only idle CPU which doesn't turn off it's ticks.

This CPU relinquishes it's role as the idle load balancer when
a) it finds a runnable task in it's runqueue, i.e before exiting idle state.
OR
b) all the CPUs in the system go idle.

Since it doesn't turn off it's ticks, it calls select_nohz_load_balancer() every scheduler tick, and thus can observe that it's no longer set in cpu_active_map within a tick or two.

Also, the cpu_down() path calls migrate_timers() in CPU_DEAD:,i.e after the CPU has gone down. But to take the CPU down, we would have invoked the stop_machine_run() code on that CPU, which by itself would make the CPU relinquish it's role as the idle load balancer owing to condition (a).

Thus I believe, mod_timer() can never migrate a timer on to a DEAD CPU, during/_after_ we invoke migrate_timers() from the CPU_DEAD callpath.

Quoted 20 lines · Gautham R Shenoy

.load_balancer is the idle load balancer CPU which performs load balancing on behalf of all the idle cpus in the system. It's the only idle CPU which doesn't turn off it's ticks.

This CPU relinquishes it's role as the idle load balancer when
a) it finds a runnable task in it's runqueue, i.e before exiting idle state.
OR
b) all the CPUs in the system go idle.

Since it doesn't turn off it's ticks, it calls select_nohz_load_balancer() every scheduler tick, and thus can observe that it's no longer set in cpu_active_map within a tick or two.

Also, the cpu_down() path calls migrate_timers() in CPU_DEAD:,i.e after the CPU has gone down. But to take the CPU down, we would have invoked the stop_machine_run() code on that CPU, which by itself would make the CPU relinquish it's role as the idle load balancer owing to condition (a).

Quoted 2 lines

Thus I believe, mod_timer() can never migrate a timer on to a DEAD CPU, during/_after_ we invoke migrate_timers() from the CPU_DEAD callpath.

OK, thanks a lot for your explanation!

Oleg.

Quoted 20 lines · Gautham R Shenoy

.load_balancer is the idle load balancer CPU which performs load balancing on behalf of all the idle cpus in the system. It's the only idle CPU which doesn't turn off it's ticks.

This CPU relinquishes it's role as the idle load balancer when
a) it finds a runnable task in it's runqueue, i.e before exiting idle state.
OR
b) all the CPUs in the system go idle.

Since it doesn't turn off it's ticks, it calls select_nohz_load_balancer() every scheduler tick, and thus can observe that it's no longer set in cpu_active_map within a tick or two.

Also, the cpu_down() path calls migrate_timers() in CPU_DEAD:,i.e after the CPU has gone down. But to take the CPU down, we would have invoked the stop_machine_run() code on that CPU, which by itself would make the CPU relinquish it's role as the idle load balancer owing to condition (a).

Quoted 2 lines

Thus I believe, mod_timer() can never migrate a timer on to a DEAD CPU, during/_after_ we invoke migrate_timers() from the CPU_DEAD callpath.

OK, thanks a lot for your explanation!

Oleg.

$taskset -c 4,5,6,7 make -j4

my_driver queuing timers continuously on CPU 10.

idle load balancer currently on CPU 15

Case1: Without timer migration Case2: With timer migration

   --------------------			   --------------------
   | Core | LOC Count |			   | Core | LOC Count |
   | 4    |   2504    |			   | 4    |   2503    |
   | 5    |   2502    |			   | 5    |   2503    |
   | 6    |   2502    |			   | 6    |   2502    |
   | 7    |   2498    |			   | 7    |   2500    |
   | 10   |   2501    |			   | 10   |     35    |
   | 15   |   2501    |			   | 15   |   2501    |
   --------------------			   --------------------

   ---------------------		   --------------------
   | Core | Sleep time |		   | Core | Sleep time |
   | 4    |    0.47168 |		   | 4    |    0.49601 |
   | 5    |    0.44301 |		   | 5    |    0.37153 |
   | 6    |    0.38979 |		   | 6    |    0.51286 |
   | 7    |    0.42829 |		   | 7    |    0.49635 |
   | 10   |    9.86652 |		   | 10   |   10.04216 |
   | 15   |    0.43048 |		   | 15   |    0.49056 |
   ---------------------		   ---------------------

Here, all the timers queued by the driver on CPU10 are moved to CPU15, which is the idle load balancer.

$taskset -c 4,5,6,7 make -j4

my_driver queuing timers continuously on CPU 10.

idle load balancer currently on CPU 15

Case1: Without timer migration Case2: With timer migration

   --------------------			   --------------------
   | Core | LOC Count |			   | Core | LOC Count |
   | 4    |   2504    |			   | 4    |   2503    |
   | 5    |   2502    |			   | 5    |   2503    |
   | 6    |   2502    |			   | 6    |   2502    |
   | 7    |   2498    |			   | 7    |   2500    |
   | 10   |   2501    |			   | 10   |     35    |
   | 15   |   2501    |			   | 15   |   2501    |
   --------------------			   --------------------

   ---------------------		   --------------------
   | Core | Sleep time |		   | Core | Sleep time |
   | 4    |    0.47168 |		   | 4    |    0.49601 |
   | 5    |    0.44301 |		   | 5    |    0.37153 |
   | 6    |    0.38979 |		   | 6    |    0.51286 |
   | 7    |    0.42829 |		   | 7    |    0.49635 |
   | 10   |    9.86652 |		   | 10   |   10.04216 |
   | 15   |    0.43048 |		   | 15   |    0.49056 |
   ---------------------		   ---------------------

Here, all the timers queued by the driver on CPU10 are moved to CPU15, which is the idle load balancer.

Quoted 29 lines · Arun R Bharadwaj

$taskset -c 4,5,6,7 make -j4

my_driver queuing timers continuously on CPU 10.

idle load balancer currently on CPU 15

Case1: Without timer migration Case2: With timer migration

   --------------------			   --------------------
   | Core | LOC Count |			   | Core | LOC Count |
   | 4    |   2504    |			   | 4    |   2503    |
   | 5    |   2502    |			   | 5    |   2503    |
   | 6    |   2502    |			   | 6    |   2502    |
   | 7    |   2498    |			   | 7    |   2500    |
   | 10   |   2501    |			   | 10   |     35    |
   | 15   |   2501    |			   | 15   |   2501    |
   --------------------			   --------------------

   ---------------------		   --------------------
   | Core | Sleep time |		   | Core | Sleep time |
   | 4    |    0.47168 |		   | 4    |    0.49601 |
   | 5    |    0.44301 |		   | 5    |    0.37153 |
   | 6    |    0.38979 |		   | 6    |    0.51286 |
   | 7    |    0.42829 |		   | 7    |    0.49635 |
   | 10   |    9.86652 |		   | 10   |   10.04216 |
   | 15   |    0.43048 |		   | 15   |    0.49056 |
   ---------------------		   ---------------------

Quoted 2 lines

Here, all the timers queued by the driver on CPU10 are moved to CPU15, which is the idle load balancer.

The numbers with this automatic method based on the ilb-cpu look pretty convincing. Is this what you expected it to be?

Quoted 32 lines · Ingo Molnar

Quoted 29 lines · Arun R Bharadwaj

$taskset -c 4,5,6,7 make -j4

my_driver queuing timers continuously on CPU 10.

idle load balancer currently on CPU 15

Case1: Without timer migration Case2: With timer migration

   --------------------			   --------------------
   | Core | LOC Count |			   | Core | LOC Count |
   | 4    |   2504    |			   | 4    |   2503    |
   | 5    |   2502    |			   | 5    |   2503    |
   | 6    |   2502    |			   | 6    |   2502    |
   | 7    |   2498    |			   | 7    |   2500    |
   | 10   |   2501    |			   | 10   |     35    |
   | 15   |   2501    |			   | 15   |   2501    |
   --------------------			   --------------------

   ---------------------		   --------------------
   | Core | Sleep time |		   | Core | Sleep time |
   | 4    |    0.47168 |		   | 4    |    0.49601 |
   | 5    |    0.44301 |		   | 5    |    0.37153 |
   | 6    |    0.38979 |		   | 6    |    0.51286 |
   | 7    |    0.42829 |		   | 7    |    0.49635 |
   | 10   |    9.86652 |		   | 10   |   10.04216 |
   | 15   |    0.43048 |		   | 15   |    0.49056 |
   ---------------------		   ---------------------

Quoted 5 lines

Quoted 2 lines

Here, all the timers queued by the driver on CPU10 are moved to CPU15, which is the idle load balancer.

The numbers with this automatic method based on the ilb-cpu look pretty convincing. Is this what you expected it to be?

Yes Ingo, this is the expected results and looks pretty good. However there are two parameters controlled in this experiment:

1) The system is moderately loaded with kernbench so that there are some busy CPUs and some idle cpus, and the no_hz mask is does not change often. This leads to stable ilb-cpu selection. If the system is either completely idle or loaded too little leading to ilb nominations, then timers keep following the ilb cpu and it is very difficult to experimentally observe the benefits.

Even if the ilb bounces, consolidating timers should increase overlap between timers and reduce the wakeup from idle.

Optimising the ilb selection should significantly improve experimental results for this patch.

2) The timer test driver creates quite large timer load so that the effect of migration is observable as sleep time difference on the expected target cpu. This kind of timer load may not be uncommon with lots of application stack loaded in an enterprise system

Quoted 32 lines · Ingo Molnar

Quoted 29 lines · Arun R Bharadwaj

$taskset -c 4,5,6,7 make -j4

my_driver queuing timers continuously on CPU 10.

idle load balancer currently on CPU 15

Case1: Without timer migration Case2: With timer migration

   --------------------			   --------------------
   | Core | LOC Count |			   | Core | LOC Count |
   | 4    |   2504    |			   | 4    |   2503    |
   | 5    |   2502    |			   | 5    |   2503    |
   | 6    |   2502    |			   | 6    |   2502    |
   | 7    |   2498    |			   | 7    |   2500    |
   | 10   |   2501    |			   | 10   |     35    |
   | 15   |   2501    |			   | 15   |   2501    |
   --------------------			   --------------------

   ---------------------		   --------------------
   | Core | Sleep time |		   | Core | Sleep time |
   | 4    |    0.47168 |		   | 4    |    0.49601 |
   | 5    |    0.44301 |		   | 5    |    0.37153 |
   | 6    |    0.38979 |		   | 6    |    0.51286 |
   | 7    |    0.42829 |		   | 7    |    0.49635 |
   | 10   |    9.86652 |		   | 10   |   10.04216 |
   | 15   |    0.43048 |		   | 15   |    0.49056 |
   ---------------------		   ---------------------

Quoted 5 lines

Quoted 2 lines

Here, all the timers queued by the driver on CPU10 are moved to CPU15, which is the idle load balancer.

The numbers with this automatic method based on the ilb-cpu look pretty convincing. Is this what you expected it to be?

Yes Ingo, this is the expected results and looks pretty good. However there are two parameters controlled in this experiment:

1) The system is moderately loaded with kernbench so that there are some busy CPUs and some idle cpus, and the no_hz mask is does not change often. This leads to stable ilb-cpu selection. If the system is either completely idle or loaded too little leading to ilb nominations, then timers keep following the ilb cpu and it is very difficult to experimentally observe the benefits.

Even if the ilb bounces, consolidating timers should increase overlap between timers and reduce the wakeup from idle.

Optimising the ilb selection should significantly improve experimental results for this patch.

2) The timer test driver creates quite large timer load so that the effect of migration is observable as sleep time difference on the expected target cpu. This kind of timer load may not be uncommon with lots of application stack loaded in an enterprise system

Quoted 29 lines · Arun R Bharadwaj

$taskset -c 4,5,6,7 make -j4

my_driver queuing timers continuously on CPU 10.

idle load balancer currently on CPU 15

Case1: Without timer migration Case2: With timer migration

   --------------------			   --------------------
   | Core | LOC Count |			   | Core | LOC Count |
   | 4    |   2504    |			   | 4    |   2503    |
   | 5    |   2502    |			   | 5    |   2503    |
   | 6    |   2502    |			   | 6    |   2502    |
   | 7    |   2498    |			   | 7    |   2500    |
   | 10   |   2501    |			   | 10   |     35    |
   | 15   |   2501    |			   | 15   |   2501    |
   --------------------			   --------------------

   ---------------------		   --------------------
   | Core | Sleep time |		   | Core | Sleep time |
   | 4    |    0.47168 |		   | 4    |    0.49601 |
   | 5    |    0.44301 |		   | 5    |    0.37153 |
   | 6    |    0.38979 |		   | 6    |    0.51286 |
   | 7    |    0.42829 |		   | 7    |    0.49635 |
   | 10   |    9.86652 |		   | 10   |   10.04216 |
   | 15   |    0.43048 |		   | 15   |    0.49056 |
   ---------------------		   ---------------------

Quoted 2 lines

Here, all the timers queued by the driver on CPU10 are moved to CPU15, which is the idle load balancer.

The numbers with this automatic method based on the ilb-cpu look pretty convincing. Is this what you expected it to be?

With the timers queued I measure the sleep state residency for a period of 10s.
Next, I enable timer migration and measure the sleep state residency period.

Quoted 4 lines · On Wed, 4 Mar 2009 17:42:49 +0530 Arun R Bharadwaj <[email protected]>…

With the timers queued I measure the sleep state residency for a period of 10s.
Next, I enable timer migration and measure the sleep state residency period.

is your table in seconds? Because realistically, at least on PC like hardware, doing work to get sleep times over a 100 / 200 msecs or so isn't going to save you any amount of measurable power anymore...

Signature · 4 lines

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Quoted 4 lines · On Wed, 4 Mar 2009 17:42:49 +0530 Arun R Bharadwaj <[email protected]>…

With the timers queued I measure the sleep state residency for a period of 10s.
Next, I enable timer migration and measure the sleep state residency period.

is your table in seconds? Because realistically, at least on PC like hardware, doing work to get sleep times over a 100 / 200 msecs or so isn't going to save you any amount of measurable power anymore...

Signature · 4 lines

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

With the timers queued I measure the sleep state residency for a period of 10s.
Next, I enable timer migration and measure the sleep state residency period.