Re: Slow pty's (was Re: libdivecomputer interfaces?)

[Peter Zijlstra <peterz@infradead.org>]

On Thu, 2010-06-17 at 12:50 +0200, Mike Galbraith wrote:

> sched: do not ratelimit NOHZ when the tick is stopped.
> 
> Chris Wedgwood reports that 39c0cbe sched: Rate-limit nohz causes a serial
> console regression, unresponsiveness, and indeed it does.  The below fixes
> it by not skipping out when the tick has been stopped.
> 
> Tested that the throughput benefit of ratelimiting is still intact.  It is.
> 
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> Reported-by: Chris Wedgwood <cw@f00f.org>

> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 5f171f0..83c5129 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -315,7 +315,7 @@ void tick_nohz_stop_sched_tick(int inidle)
>  		goto end;
>  	}
>  
> -	if (nohz_ratelimit(cpu))
> +	if (!ts->tick_stopped && nohz_ratelimit(cpu))
>  		goto end;
>  
>  	ts->idle_calls++;
>  


Humm,. the code around there suggests something like the below, but I
must admit its been a while since I really read all that nohz stuff,
Thomas, any preferences?

---
 kernel/time/tick-sched.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 5f171f0..e0707ea 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -315,9 +315,6 @@ void tick_nohz_stop_sched_tick(int inidle)
 		goto end;
 	}
 
-	if (nohz_ratelimit(cpu))
-		goto end;
-
 	ts->idle_calls++;
 	/* Read jiffies and the time when jiffies were updated last */
 	do {
@@ -328,7 +325,7 @@ void tick_nohz_stop_sched_tick(int inidle)
 	} while (read_seqretry(&xtime_lock, seq));
 
 	if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu) ||
-	    arch_needs_cpu(cpu)) {
+	    arch_needs_cpu(cpu) || nohz_ratelimit(cpu)) {
 		next_jiffies = last_jiffies + 1;
 		delta_jiffies = 1;
 	} else {