必须通过/proc/[pid]/status等内核虚拟文件读取内核线程详细信息，因其无用户空间、不显示在ps/top默认字段中；pid
要在麒麟OS中获取系统内核进程的详细信息，必须区分“内核线程”与普通用户进程——内核线程（如kthreadd、ksoftirqd、migration等）没有可执行文件路径、不归属任何用户、PID通常小于1000，且其状态和内存占用只能通过/proc/[PID]/stat、/proc/[PID]/status等内核虚拟文件直接读取，无法用ps或top的默认字段完整呈现。
确认内核线程PID范围并筛选真实内核进程
内核线程在/proc目录下以数字命名的子目录存在，但并非所有低PID都是内核线程；需结合comm字段过滤。执行：ls /proc/[0-9]*/comm 2>/dev/null | xargs -I{} sh -c 'echo $(basename $(dirname {})) $(cat {})'，输出中第二列为括号内名称（如kthreadd、rcu_gp、khungtaskd）的才是真内核线程。注意：【PID为2的进程一定是kthreadd，它是所有内核线程的父进程，不可终止】。
这一步跳过ps aux的干扰项——ps会把部分内核线程显示为“[kthreadd]”，但%MEM、VSZ等字段为0，不具备参考价值。
读取指定内核线程的完整状态信息
选中一个内核线程PID（例如2），执行：cat /proc/2/status。该文件包含Name、State、Tgid、Ngid、PPid、Threads、voluntary_ctxt_switches、nonvoluntary_ctxt_switches等30+字段，其中：
State字段值为R（运行）、S（可中断睡眠）、D（不可中断睡眠）——若某内核线程长期处于D态，可能正卡在硬件等待（如磁盘IO未响应）；Threads字段显示该线程组内总线程数，对kthreadd而言通常远大于1；CapEff字段是能力掩码，全为0表示无任何Linux capability权限。
不要用cat /proc/2/stat替代——stat格式紧凑但字段顺序固定且无标签，第3列是State、第4列是PPid、第14列是utime、第15列是stime，极易看错列序。
查看内核线程的CPU时间与调度细节
方法一：解析/proc/[PID]/stat获取精确CPU耗时
执行：awk '{print "utime=" $14/100 "s, stime=" $15/100 "s, priority=" $18 ", nice=" $19}' /proc/2/stat。结果中utime与stime单位为厘秒（centisecond），除以100转为秒；priority值越小优先级越高，内核线程通常为-2、-1或0；nice值恒为0，因内核线程不参与用户态nice调度。
方法二：用ps命令强制显示内核线程调度参数
执行：ps -p 2 -o pid,tid,cls,pri,rtprio,nice,comm。其中cls显示调度策略（FF=实时先到先服务，TS=完全公平调度），rtprio仅对FF策略有效，值越大实时优先级越高；对kthreadd这类线程，cls为TS、rtprio为—、pri为120（CFS默认值）。
检查内核线程打开的文件与内存映射
内核线程不使用用户空间文件描述符，因此lsof -p 2 或 ls /proc/2/fd/ 均为空或报错“No such file or directory”，这是正常现象，不代表异常。若命令意外返回文件列表，说明该PID已被复用为用户进程，原内核线程已退出。
执行：cat /proc/2/maps 将返回空内容或仅一行“00000000-00000000”——因为内核线程不拥有用户地址空间，其代码段、数据段全部位于内核态高地址（0xffff...），不暴露在maps中。试图用pmap -x 2会提示“readlink: No such file or directory”，原因相同。
动态追踪内核线程的上下文切换与唤醒行为
第一步：启用ftrace跟踪器
执行：echo function_graph > /sys/kernel/debug/tracing/current_tracer，然后echo kthreadd > /sys/kernel/debug/tracing/set_ftrace_pid（需root权限）。这将只记录kthreadd及其子线程的函数调用图。
第二步：触发采样并提取关键事件
执行：echo 1 > /sys/kernel/debug/tracing/tracing_on → 等待3秒 → echo 0 > /sys/kernel/debug/tracing/tracing_on → cat /sys/kernel/debug/tracing/trace | grep -E "(wake_up|schedule|try_to_wake_up)" | head -20。
输出中每行含时间戳、CPU编号、进程名、函数名及缩进层级；若看到大量“try_to_wake_up→activate_task”嵌套，说明该内核线程被频繁唤醒，可能与软中断负载过高有关。注意：【/sys/kernel/debug/tracing/目录默认仅root可写，普通用户需sudo或切换root执行】。
