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]

Message-ID: <20100610181042.GA19210@puku.stupidest.org>
Date:	Thu, 10 Jun 2010 11:10:42 -0700
From:	Chris Wedgwood <cw@...f.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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
Subject: Re: Slow pty's (was Re: libdivecomputer interfaces?)

(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.


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