Since https://svnweb.freebsd.org/base?view=revision&revision=317659, devices connected through a serial device and using a low baudrate seems to eat a lot more cpu than before. This has been constated using a lcd screen with a baudrate of 2400. Using pmc, I got this: PMC: [CPU_CLK_UNHALTED.THREAD_P] Samples: 14 (100.0%) , 0 unresolved %SAMP CALLTREE 85.7 amd64_syscall@kernel sys_write kern_writev dofilewrite devfs_write_f ttydev_write ttydisc_write tty_wait _cv_wait_sig __mtx_lock_sleep lock_delay(85.7%) 7.1 _start@xxx <no relevent information here>(7.1%) 7.1 _start@xxx <no relevent information here>(7.1%) Reverting this commit made the call to lock_delay disappear and the performances of my test system back to normal.
^Triage: CC committer of base r317659 and request feedback
That effect is unexpected to me. I would expect opposite -- reduction of wait time, since code reduces number of buffer flushes and utilizes hardware FIFO. I may need to reproduce it to understand the issue. What UART hardware are you using? Does it have FIFO?
A commit references this bug: Author: mav Date: Sun Sep 15 23:56:40 UTC 2019 New revision: 352369 URL: https://svnweb.freebsd.org/changeset/base/352369 Log: Relax TX draining in ns8250_bus_transmit(). Since TX interrupt is generated when THRE is set, wait for TEMT set means wait for full character transmission time. At low speeds that may take awhile, burning CPU time while holding sc_hwmtx lock, also congested. This is partial revert of r317659. PR: 240121 MFC after: 2 weeks Changes: head/sys/dev/uart/uart_dev_ns8250.c
Please try this patch. I think the problem indeed was caused by my change.
(In reply to Alexander Motin from comment #4) We did some tests of this patch last week. So far, everything looks OK :).
This looks like it has caused breakage on stable/11 (not sure about 12). Full details (do not skim): https://lists.freebsd.org/pipermail/freebsd-stable/2019-October/091630.html