lkml.org 
[lkml]   [2010]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Slow pty's (was Re: libdivecomputer interfaces?)
Date
Linus Torvalds <torvalds@linux-foundation.org> writes:

>>From Jef's original lkml report linked to above:
>
>> You can reproduce the problem by running these commands in three
>> different terminals:
>>
>> # Terminal 1: Setup the pty's.
>> socat PTY,link=/tmp/ttyS0 PTY,link=/tmp/ttyS1
>> # Terminal 2: Send some data.
>> dd if=/dev/urandom of=input.bin bs=538368 count=1
>> sx input.bin >>/tmp/ttyS0 </tmp/ttyS0
>> # Terminal 2: Receive the data data.
>> time rx output.bin >/tmp/ttyS1 </tmp/ttyS1
>
> and yeah, it's pretty clear to see. A "perf report" on that receiving
> side just shows queue_delayed_work_on(), but that doesn't mean much.
> It's clearly just sleeping all the time...

I'm not reading all of this thread yet, so sorry if I'm missing the
point of this thread.

FWIW, I remember there was the unnecessary waiting related to background
flusher. It was in input_available_p(). I'm not sure at all whether
this is related to the problem, and totally untested patch (this patch
calls tty_flush_to_ldisc() only when data is unavailable). Someone can
test the following or something (is there any change)?

Well, anyway, I'll read this thread at this weekend, and will see if
someone didn't already fix it.


I.e. the following or something,

static inline int input_available_p(struct tty_struct *tty, int amt)
{
int try = 0;

retry:
if (tty->icanon) {
if (tty->canon_data)
return 1;
} else if (tty->read_cnt >= (amt ? amt : 1))
return 1;

if (!checked) {
tty_flush_to_ldisc(tty);
try = 1;
goto retry;
}

return 0;
}

--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


\
 
 \ /
  Last update: 2010-06-10 20:09    [W:0.135 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site