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

[Mike Galbraith <efault@gmx.de>]

On Thu, 2010-06-17 at 09:00 +0200, Mike Galbraith wrote:
> On Thu, 2010-06-17 at 08:39 +0200, Mike Galbraith wrote:
> 
> > I'm not seeing any problem with serial console here, seems to work just
> > fine P4->Q6600, both running NOHZ kernels with nohz_ratelimit(), 33.5 on
> > the P4, and tip.today on the Q6600.
> 
> Of course, as soon as I say that, the problem appeared.  Hopefully,
> It'll stick around a while.

Actually, it's fully reproducible, I just have _way_ too many (49)
kernels to choose from.

I had to go back to virgin 34, apply 39c0cbe and fixlet to fully test,
as git/tip network isn't working quite right for me atm.  At any rate,
the below fixed it up for me, and cross-cpu throughput gain is intact.

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>
LKML-Reference: <new-submission>

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