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

[Chris Wedgwood <cw@f00f.org>]

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