linux – 如果超过256个字符待处理,为什么8250 UART驱动程序不会唤醒TTY？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了linux – 如果超过256个字符待处理,为什么8250 UART驱动程序不会唤醒TTY？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1871字，纯文字阅读大概需要3分钟。

内容图文

void serial8250_tx_chars(struct uart_8250_port * up)中这个if条件的动机是什么？

if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
    uart_write_wakeup(port);

自从Linux 1.1.13(1994年5月)以来,它一直存在并且在大多数UART驱动程序中重复.

背景：定制的Linux 3.4.91,ARMv7上的嵌入式系统,UART端口0配置为38400波特,16字节FIFO用于i / o.这些都不能在我们的设置中更改.

当通过UART在控制台上非常大量地打印时,内部4kB缓冲区(UART_XMIT_SIZE)会填满,然后停止用户空间进程,直到缓冲区被清空(这需要一秒钟在38400波特！).然后这种行为重复.这是因为函数n_tty_write()在缓冲区已满时进入休眠状态,并且由于上述可疑条件而未长时间被唤醒.

如果简单地删除这个检查,我会发现它更自然和有效.然后printfs会尽可能快地填充缓冲区,然后以缓冲区清空的速度继续,而不是我正在观察的突发处理.

它在我的环境中工作正常,但我肯定错过了或误解了一些东西.目前的实施必须有一个原因.如果我删除那个条件会有副作用吗？

作为一个侧面问题：是否有用于调整此行为的配置选项,例如：如果缓冲区已满,printf总是立即返回并丢弃输出？

解决方法:

这是一种效率措施. CPU的运行速度比串行端口快得多,如果内核允许用户空间进程每次在缓冲区中有一点空间时运行,它最终会向用户空间移动并返回每个字节的数据.这非常浪费CPU时间：

$time dd if=/dev/zero of=/dev/null bs=1 count=10000000
10000000+0 records in
10000000+0 records out
10000000 bytes (10 MB, 9.5 MiB) copied, 5.95145 s, 1.7 MB/s

real    0m5.954s
user    0m1.960s
sys     0m3.992s

$time dd if=/dev/zero of=/dev/null bs=1000 count=10000
10000+0 records in
10000+0 records out
10000000 bytes (10 MB, 9.5 MiB) copied, 0.011041 s, 906 MB/s

real    0m0.014s
user    0m0.000s
sys     0m0.012s

上述测试甚至不是在读取和编写真实设备：整个时间差异是系统在用户空间和内核空间之间弹跳的频率.

如果用户空间不想被阻止,它可以使用非阻塞I / O,或者它可以检查使用select()调用来查看是否有空间写入设备…如果没有,则它可以将余数转储到自己的缓冲区中并继续处理.不可否认,这确实使事情复杂化,因为现在你有一个缓冲区,你必须刷新……但如果你使用stdio,那通常都是正确的.

内容总结

以上是互联网集市为您收集整理的linux – 如果超过256个字符待处理,为什么8250 UART驱动程序不会唤醒TTY？全部内容，希望文章能够帮你解决linux – 如果超过256个字符待处理,为什么8250 UART驱动程序不会唤醒TTY？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---