Re: Slow pty's (was Re: libdivecomputer interfaces?)
From: OGAWA Hirofumi
Date: Thu Jun 10 2010 - 14:07:21 EST
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/