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:	Wed, 16 Jun 2010 17:03:22 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Brian Bloniarz <bmb@...enacr.com>
Cc:	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, Mike Galbraith <efault@....de>
Subject: Re: Slow pty's (was Re: libdivecomputer interfaces?)

On Thu, 10 Jun 2010, Brian Bloniarz wrote:

> On 06/10/2010 02:10 PM, Chris Wedgwood wrote:
> > (sorry if this reponse isn't on target, i was just pointed to this
> > thread a few minutes ago)
> > 
> > 
> > On Thu, Jun 10, 2010 at 10:25:36AM -0700, Linus Torvalds wrote:
> > 
> >>  I thought we long since (ie back last fall) fixed the latency
> >> problems with pty's, but there does seem to be something very fishy
> >> going on there still.
> > 
> > this might not be related, but i have slow serial ports with NOHZ that
> > goes away when i revert 39c0cbe2150cbd848a25ba6cdb271d1ad46818ad.
> 
> Unrelated or not, I think Chris is right about this. Somewhere before
> -rc1, the emulated serial console on my KVM instance became slow
> to echo input. I just tested with the commit reverted and it's
> back to normal.

So let's CC Mike then.

> 
> > commit 39c0cbe2150cbd848a25ba6cdb271d1ad46818ad
> > Author: Mike Galbraith <efault@....de>
> > Date:   Thu Mar 11 17:17:13 2010 +0100
> > 
> >     sched: Rate-limit nohz
> > 
> >     Entering nohz code on every micro-idle is costing ~10% throughput for netperf
> >     TCP_RR when scheduling cross-cpu.  Rate limiting entry fixes this, but raises
> >     ticks a bit.  On my Q6600, an idle box goes from ~85 interrupts/sec to 128.
> > 
> >     The higher the context switch rate, the more nohz entry costs.  With this patch
> >     and some cycle recovery patches in my tree, max cross cpu context switch rate is
> >     improved by ~16%, a large portion of which of which is this ratelimiting.
> > 
> > and looking at the only two interesting hunks it's not clear why:
> > 
> > +int nohz_ratelimit(int cpu)
> > +{
> > +       struct rq *rq = cpu_rq(cpu);
> > +       u64 diff = rq->clock - rq->nohz_stamp;
> > +
> > +       rq->nohz_stamp = rq->clock;
> > +
> > +       return diff < (NSEC_PER_SEC / HZ) >> 1;
> > +}
> > 
> > +       if (nohz_ratelimit(cpu))
> > +               goto end;
> > +
> > 
> > network latnecy is fine, and if i create lots of wakeups (network IO
> > is fine) then the serial port latency is noticable

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

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