Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932757Ab0FQKuu (ORCPT <rfc822;w@1wt.eu>);
	Thu, 17 Jun 2010 06:50:50 -0400
Received: from mail.gmx.net ([213.165.64.20]:46196 "HELO mail.gmx.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
	id S932155Ab0FQKus (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 17 Jun 2010 06:50:48 -0400
X-Authenticated: #14349625
X-Provags-ID: V01U2FsdGVkX1/fgLQRHSrflCb2HCNPCVbCVDDL1pFEoGvZbDgxkl
	gyR+B9AODanefl
Subject: Re: Slow pty's (was Re: libdivecomputer interfaces?)
From: Mike Galbraith <efault@gmx.de>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Brian Bloniarz <bmb@athenacr.com>, Chris Wedgwood <cw@f00f.org>,
       Linus Torvalds <torvalds@linux-foundation.org>,
       Greg KH <gregkh@suse.de>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
       OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
       Jef Driesen <jefdriesen@telenet.be>, linux-kernel@vger.kernel.org,
       Peter Zijlstra <a.p.zijlstra@chello.nl>, Ingo Molnar <mingo@elte.hu>
In-Reply-To: <1276758038.9628.1.camel@marge.simson.net>
References: <AANLkTinLth4iKXAwszEEsPm_9ZDlj8HtqsiG5cdFE1cZ@mail.gmail.com>
	 <20100610181042.GA19210@puku.stupidest.org> <4C116652.8010408@athenacr.com>
	 <alpine.LRH.2.00.1006161702470.2497@twin.jikos.cz>
	 <1276701411.30669.6.camel@marge.simson.net>
	 <1276756770.8248.20.camel@marge.simson.net>
	 <1276758038.9628.1.camel@marge.simson.net>
Content-Type: text/plain
Date: Thu, 17 Jun 2010 12:50:44 +0200
Message-Id: <1276771844.8121.14.camel@marge.simson.net>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.1.1 
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1780
Lines: 49

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/