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 10:56:15 -0400
From:	Brian Bloniarz <bmb@...enacr.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Mike Galbraith <efault@....de>, Jiri Kosina <jkosina@...e.cz>,
	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>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Slow pty's (was Re: libdivecomputer interfaces?)

On 06/17/2010 09:24 AM, 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?

I tested Peter's variant, it eliminates the kvm console echo latency
that I was seeing. (I haven't tried Mike's earlier variant).

Tested-by: Brian Bloniarz <bmb@...enacr.com>

> ---
>  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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ