Messages in this thread |  | | | Subject | Re: Slow pty's (was Re: libdivecomputer interfaces?) | | From | Mike Galbraith <> | | Date | Wed, 16 Jun 2010 17:16:51 +0200 |
| |
On Wed, 2010-06-16 at 17:03 +0200, Jiri Kosina wrote: > 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.
Chris already gave me a heads up, it's on my todo. The old P4 box I use for a serial console box is exploding on boot, or I would have already had a look.
> > > and looking at the only two interesting hunks it's not clear why:
Complete mystery to me.
> > > +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
|  |