|Summary:||Serial console can eat a lot of CPU with low baudrate|
|Product:||Base System||Reporter:||Masse Nicolas <nicolas.masse>|
|Component:||kern||Assignee:||Alexander Motin <mav>|
|Severity:||Affects Some People||CC:||jdc, mav|
|Priority:||---||Keywords:||needs-qa, performance, regression|
Description Masse Nicolas 2019-08-26 10:44:09 UTC
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.
Comment 1 Kubilay Kocak 2019-08-26 12:11:44 UTC
^Triage: CC committer of base r317659 and request feedback
Comment 2 Alexander Motin 2019-08-26 13:55:34 UTC
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?
Comment 3 commit-hook 2019-09-15 23:56:42 UTC
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
Comment 4 Alexander Motin 2019-09-16 00:01:27 UTC
Please try this patch. I think the problem indeed was caused by my change.
Comment 5 Masse Nicolas 2019-09-30 07:36:21 UTC
(In reply to Alexander Motin from comment #4) We did some tests of this patch last week. So far, everything looks OK :).
Comment 6 Jeremy Chadwick 2019-10-31 09:48:21 UTC
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