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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87typan4mu.fsf@devron.myhome.or.jp>
Date:	Fri, 11 Jun 2010 03:07:05 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Greg KH <gregkh@...e.de>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jef Driesen <jefdriesen@...enet.be>,
	linux-kernel@...r.kernel.org
Subject: Re: Slow pty's (was Re: libdivecomputer interfaces?)

Linus Torvalds <torvalds@...ux-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@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/