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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jun 2010 16:11:59 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Mike Galbraith <efault@....de>, Jiri Kosina <jkosina@...e.cz>,
	Brian Bloniarz <bmb@...enacr.com>,
	Chris Wedgwood <cw@...f.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Jef Driesen <jefdriesen@...enet.be>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: Slow pty's (was Re: libdivecomputer interfaces?)

On Thu, 17 Jun 2010, Peter Zijlstra wrote:

> 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@....de>
> > Reported-by: Chris Wedgwood <cw@...f.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?

The version below is better as it solves the problem and follows the
nohz_ratelimit() advise even in the case where it changes after the
tick has been stopped.

Thanks,

	tglx
> ---
>  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 {
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/