LatencyTOP이 루프 테스트의 테스트 단계에서 그렇게 많은 대기 시간을 캡처하는 이유

LatencyTOP이 루프 테스트의 테스트 단계에서 그렇게 많은 대기 시간을 캡처하는 이유

저는 RT 패치가 적용되고 활성화된 맞춤형 Linux 시스템을 사용하고 있습니다 LatencyTOP. 단계에서 d를 사용하여 대기 시간 정보를 캡처했는데 특히 및 cyclictest에서 지연이 많이 발생하는 것을 발견했습니다 . 이것이 정상입니까?hrtimer_nanosleepdo_select

#1:

taskset -c 2 cyclictest -t 1 -p 80 -n -i 1000 -l 1000000000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 1.45 1.25 0.75 1/131 4401

T: 0 (  875) P:80 I:1000 C: 764021 Min:      2 Act:    4 Avg:    3 Max:      28

#2:

cat /proc/latency_stats
Latency Top version : v0.1
549481 534022296 982 hrtimer_nanosleep common_nsleep_timens __x64_sys_clock_nanosleep do_syscall_64 entry_SYSCALL_64_after_hwframe
2191 1159065 1151 do_wait kernel_wait4 do_syscall_64 entry_SYSCALL_64_after_hwframe
4500 2626162 4999 do_select core_sys_select do_pselect.constprop.0 __x64_sys_pselect6 do_syscall_64 entry_SYSCALL_64_after_hwframe
76 38535 599 do_get_write_access jbd2_journal_get_write_access __ext4_journal_get_write_access ext4_reserve_inode_write __ext4_mark_inode_dirty ext4_dirty_inode __mark_inode_dirty touch_atime step_into path_openat do_filp_open do_open_execat
12 34 7 wait_transaction_locked add_transaction_credits start_this_handle jbd2__journal_start ext4_dirty_inode __mark_inode_dirty touch_atime filemap_read __kernel_read bprm_execve do_execveat_common.isra.0 __x64_sys_execve
4 170 43 usb_start_wait_urb usb_control_msg f81604_get_register [f81604] f81604_get_berr_counter [f81604] can_fill_info [can_dev] rtnl_fill_ifinfo rtnl_dump_ifinfo netlink_dump netlink_recvmsg ____sys_recvmsg ___sys_recvmsg __sys_recvmsg
4 198 76 usb_start_wait_urb usb_control_msg f81604_get_register [f81604] f81604_get_berr_counter [f81604] can_fill_info [can_dev] rtnl_fill_ifinfo rtnl_dump_ifinfo netlink_dump netlink_recvmsg ____sys_recvmsg ___sys_recvmsg __sys_recvmsg
3 21 15 __flush_work.isra.0 n_tty_poll tty_poll do_select core_sys_select do_pselect.constprop.0 __x64_sys_pselect6 do_syscall_64 entry_SYSCALL_64_after_hwframe

관련 정보