linux-kernel - Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)

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-next>] [day] [month] [year] [list]

Date:	Fri, 03 May 2013 19:02:46 +0400
From:	Stas Sergeev <stsp@...t.ru>
To:	Jarkko Huijts <jarkko.huijts@...il.com>
CC:	Alan Cox <alan@...ux.intel.com>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Caylan Van Larson <i@...lan.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)

Hi.

We have a regression because of this patch:
http://lkml.indiana.edu/hypermail/linux/kernel/1210.1/01456.html
While it is arguably reasonable to have this for tcdrain or close,
it also slows down poll/select a lot because n_tty_poll() does this:

tty_chars_in_buffer(tty) < WAKEUP_CHARS

And it also slows down TIOCOUTQ ioctl I think (not measured).
The slowdown of select() is big, the customer reports the inability
to work that way.

Is this patch really needed? I mean, if the time to check TEMT is
longer than to xmit that char, then what's the use?
Or, if it is really a big deal, I guess it would be necessary to add
a separate, .chars_in_buffer_fast method.

Thoughts?
--
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/