From linux-kernel Thu Jun 10 18:10:42 2010 From: Chris Wedgwood Date: Thu, 10 Jun 2010 18:10:42 +0000 To: linux-kernel Subject: Re: Slow pty's (was Re: libdivecomputer interfaces?) Message-Id: <20100610181042.GA19210 () puku ! stupidest ! org> X-MARC-Message: https://marc.info/?l=linux-kernel&m=127619405831144 (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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/