When booting FreeBSD 14 on Xen as dom0, top shows interrupt usage pretty consistently > 50% even when the system is idle. Perhaps this is an accounting error as the system seems responsive.
Created attachment 248948 [details] Fix thread nesting accounting Can you please give this a try? It was indeed a cosmetic issue, so performance wise you should be OK without the patch.
Hi Roger. After applying your patch, the interrupt usage in top now looks normal. Thanks again for your help with this!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f750dce972efaea614aa6d03ecdb24aa962a38a4 commit f750dce972efaea614aa6d03ecdb24aa962a38a4 Author: Roger Pau Monné <royger@FreeBSD.org> AuthorDate: 2024-03-05 13:15:03 +0000 Commit: Roger Pau Monné <royger@FreeBSD.org> CommitDate: 2024-04-16 07:06:33 +0000 x86/xen: fix accounted interrupt time The current addition to the interrupt nesting level in xen_arch_intr_handle_upcall() needs to be compensated in xen_intr_handle_upcall(), otherwise interrupts dispatched by the upcall handler end up seeing a td_intr_nesting_level of 2 or more, which makes them assume there's been an interrupt nesting. Such extra interrupt nesting count lead to statclock() reporting idle time as interrupt, as the call from interrupt context will always be seen as a nested one (td->td_intr_nesting_level >= 2) due to the nesting count increase done by both xen_arch_intr_handle_upcall() and intr_execute_handlers(). Fix this by adjusting the nested interrupt count before dispatching interrupts from xen_intr_handle_upcall(). PR: 277231 Reported by: Matthew Grooms <mgrooms@shrew.net> Fixes: af610cabf1f4 ('xen/intr: adjust xen_intr_handle_upcall() to match driver filter') Sponsored by: Cloud Software Group Reviewed by: Elliott Mitchell <ehem+freebsd@m5p.com> sys/dev/xen/bus/xen_intr.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)