mzhan017的博客

这个kprobetrace类似基于事件的tracepoint（跟踪点）。不过这个是基于kprobes(kprobe and kretprobe)。所有kprobe可以探测的地方，都可以使用这个kprobetrace功能。也就意味着，除了带有__kprobes/nokprobe_inline 关键字的函数，还有带有标记NOKPROBE_SYMBOL的函数外，所有的其他函数都可以做kprobetrace。而且是可以动态做探测，不像tracepoint，是静态编译在内核模块里。

摘要：批量添加IP地址的Netlink实现问题 文章探讨了通过Netlink接口批量添加大量IP地址（如数千个）时遇到的技术问题。测试发现，当尝试在一个Netlink消息中添加多个IP地址时，只有最后一个IP地址被成功添加。虽然内核代码理论上支持这种批量操作方式，但实际实现上存在问题。文章提供了相关C语言代码示例，展示了如何构造Netlink消息来添加IP地址，包括消息头的设置和属性添加的逻辑。最终问题指向需要正确构造多个独立的消息（每个IP一个消息）而非尝试在单个消息中嵌入多个IP地址。

摘要：某单核分配的Pod出现CPU高使用率（883毫核），但内部top命令未发现明显高耗进程。通过perf record系统级分析发现，一个进程因持续coredump导致不停重启，消耗大量CPU和磁盘资源。建议使用kubectl top实时监控Pod状态排查类似问题。（98字）

摘要：SCHED_IDLE是Linux引入的一种调度策略，用于只在系统空闲时运行低优先级任务。它比nice 19的优先级更低，确保任务不会干扰正常系统运行，但仍会适当调度以避免死锁。与其他策略（如SCHED_NORMAL、SCHED_BATCH）相比，SCHED_IDLE专为后台任务设计，适合病毒扫描、数据导入等场景。通过chrt或sched_setscheduler可设置该策略，其实现避免了优先级反转问题，平衡了系统响应和后台任务执行。

摘要：RHEL系统通过配置CONFIG_MLX4_DEBUG=y启用了Mellanox网卡驱动的调试日志功能。该功能通过mlx4_debug_level参数控制日志输出级别，开发者可在/etc/modprobe.d/mlnx.conf中设置debug_level=1并重启驱动来启用调试。日志通过mlx4_dbg宏输出，可用于监控网卡运行状态，如检查VXLAN隧道模式等网络配置信息。

摘要 本文分析了多线程环境下CPU使用率上升2%的性能问题。通过perf工具对比发现，内核函数中调度相关（schedule/futex）开销明显增加，网络处理函数有所下降。建议采用分层分析方法：首先定位CPU变化的主要进程，然后细化到具体线程，再通过perf抓取线程级数据进行分析。案例中最终发现是由于IP增加导致的线性查找问题，建议改用二叉树结构优化。文章提供了多线程性能问题的系统化排查思路：从进程到线程逐步细化，配合perf工具进行精准定位。

摘要：本文提供了一个Python脚本用于比较两个perf性能分析文件。脚本解析文件格式（如"0.49% ngss [kernel.kallsyms] [k] do_syscall_64"），提取第一列数值和最后一列键值，计算数值差异，并输出超过指定阈值的比较结果。使用示例显示脚本能有效识别性能差异显著的函数调用（如0x0000000010a7a176数值差异达-0.87）。脚本需传入阈值参数，仅输出差异绝对值超过该阈值的记录，便于聚焦显著性能变化。

这里可以看到即使在内核删除了网卡接口相关的信息，这个socket上的接口信息还是存在，而且变成了一个垃圾数据。创建一个 Netlink Socket（使用 socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)）。最近碰到一个问题，应用绑定到了一个GRE的interface，如下socket绑定到了bond10这个interface。解析接收到的 Netlink 消息，检查是否是 RTM_DELLINK 类型。再重新创建bond10，内核分配的新的index，12.

Envoy使用自定义错误代码5表示"MessageTooBig"，与Linux内核定义的EMSGSIZE(90)不一致。这可能导致开发者混淆，因内核定义的EIO(5)表示I/O错误。在内核UDP实现中，当发送包长度超过0xFFFF时会返回EMSGSIZE(90)。Envoy的错误代码设计未与内核保持一致，可能增加使用者的理解难度，建议统一错误代码体系以提高易用性。

使用perf工具追踪__fput函数的调用过程：首先通过"perf probe"添加__fput函数的探针，然后使用"perf record"命令记录调用栈信息。结果显示该函数主要涉及文件关闭操作，调用路径清晰可见。该方法为分析内核文件处理机制提供了有效手段。（98字）

摘要：RHEL 8.10内核启用了PREEMPT_NOTIFIERS配置项，该功能用于在任务被抢占或重新调度时通知上层处理特殊寄存器操作（如fpu或VT寄存器）。根据2007年的提交记录，该机制允许任务在切换前后执行特定操作。系统信息显示该配置存在于4.18.0-553.51.1.el8_10.x86_64内核中，运行环境为RHEL 8.10 (Ootpa)。

该程序存在CPU使用率过高问题，通过perf分析发现主要开销来自内核函数调用（如系统调用接口__kernel_vsyscall）和网络相关内核操作（如__dev_queue_xmit、packet_sendmsg等）。这表明应用程序与内核交互频繁，尤其在网络收发方面。建议将核心功能重构为内核模块以减少用户态-内核态切换开销，从而提升性能。性能瓶颈主要集中在网络数据包处理、系统调用和审计检查等内核操作上。

摘要：排查程序启动缓慢问题时，原以为是CPU耗时过高，但通过perf分析发现实际是阻塞等待。perf-report显示在sock_close操作中等待rcu_gp导致阻塞。建议将sock_close改为异步操作以解决该问题。图例展示了相关调用关系。（98字）

《查看Perf报告中的程序地址方法》摘要： 默认情况下，Perf报告会显示符号化的函数调用栈。要查看原始程序地址，使用-v或--verbose选项（而非--no-symbol），即可显示符号地址等详细信息。这一方法通过查阅man perf-report确认，ChatGPT建议的--no-symbol无效。图例显示，-v参数成功输出了包含地址的详细报告。 （字数：98）

摘要：性能分析发现audit_filter_syscall函数占用1.27% CPU，主要由于系统调用退出时逐个轮询审计规则导致开销。根据auditctl手册建议，可通过合并相同过滤条件的规则提升性能。示例展示了如何将两条规则合并为一条，并建议优先使用文件系统审计规则。系统现有70多条规则，预计审计总开销约2%，对一个占用60% CPU的服务将产生1.2%额外开销。

摘要：当使用非阻塞socket的connect接口时，若连接无法立即完成，会返回EINPROGRESS错误。这不是真正的错误，仅表示连接正在进行中。此时应用程序需通过select/poll监听socket可写事件，完成后用getsockopt检查SO_ERROR值确认连接状态。在TCP实现中，tcp_connect会启动定时器等待SYN-ACK，若超时则重发SYN，而非直接等待SYN-ACK响应。

本文探讨了在主机端关闭PF接口对分配给VM的VF接口功能无影响的现象。研究发现，当VF被分配给VM使用DPDK时，主机端的ip link set down操作不会影响VF运行状态。通过Mellanox的架构图可以看出，PF/VF都连接在Multiport E-Switch上，且主机无法看到VM使用的VF接口。文章指出需要通过特定命令（如ip link set ens15f0np0 vf 0 state disable/auto）来控制VF状态，并建议参考NVIDIA官方文档进行VF分配配置。最后通过内核调用

在网络应用中，网络问题是不可避免的，因此上层应用必须具备容错机制以应对此类问题。最近遇到的一个案例中，由于上层应用使用了Linux的epoll机制，但未设置EPOLLET标记（边缘触发），而是使用了默认的LT（水平触发）模式。在处理网络错误时，应用忽略了EPOLLERR错误，导致错误事件未被及时处理，持续触发，使得socket一直有事件需要处理，最终导致上层应用进入死循环。这一情况提醒我们，在使用epoll机制时，必须谨慎处理错误事件，避免因未及时处理而引发死循环。

最近在看一个关闭af-packet的socket慢的问题，在相关的代码调用路径里有这个函数。synchronize_net 是一个用于网络子系统中的同步操作的函数。它确保在调用该函数之前启动的所有网络处理（例如软中断处理、定时器处理等）都已经完成。这对于确保网络子系统的安全更新和删除操作非常重要。具体来说，synchronize_net 的作用是等待所有正在进行的网络处理完成，以确保在进行某些关键操作（例如删除网络设备或修改网络配置）时不会有并发访问导致数据不一致或系统崩溃。

最近和Redhat支持做一个问题分析，问了一下他们，说是：可以。但是需要需要特殊的kdump设置，来收集用户态的内存页。如果可以设置好的话，就可以方便问题的分析。这个之前我找了很久，没有找到方法。

所以又引发了另一个话题的讨论，对于接口的使用，一定要遵循规范，就是所有的返回值和errno都要考虑到。即使只关心一个，如果为了方便，其他的也可以放到一起处理。nanosleep可能返回三个errno，这里只是判断了一个EINTR，而且还和complete绑定。同时，rem变量没有初始化，所以有很大概率进入死循环。

也就是说，如果函数 A 调用了函数 B，perf report 默认会将 B 所消耗的 CPU 时间也归入到 A 中，这样你看到的 A 的性能消耗可能会包含它的子函数。使用 --no-children 参数时：perf report 只会显示每个函数自身消耗的性能数据，不再包括其子函数的消耗。在使用 perf report 命令时，–no-children 参数的作用是仅显示目标函数本身所消耗的性能资源，而不包括其子调用（即函数调用链中的下层函数）所消耗的资源。

如需要自己编译perf程序，也是非常的方便，把Linux源代码下载下来。但是需要注意，如果目标机器没有相关的类库。需要在编译时就去掉，确保没有依赖问题。就可以build出来perf了。到tools/perf下面。执行make -j 4。

最近在看Linux里的forwarding的功能。顺便在这里总结一下。有些详细代码逻辑，如果可以记录一下，会好一点。

packet_rcvarp_rcv。

里面还提到一个关于磁盘持久性问题的分析，https://puzpuzpuz.dev/the-secret-life-of-fsync，这一篇值得一看。原因是：通篇读下来，可以发现，这篇是学习内核的一个好模式（不只是内核，其他的开源软件的学习都是一样的模式）。这个Linux文件系统是不能完全保证，因为除了Linux文件系统的cache/fsync的机制之外，还有一部分是依赖于磁盘驱动的实现。所以还需要具体问题具体分析。具体分析的依据就是熟悉源代码，并且有厂商的使用说明书，厂商支持系统里的知识汇总。

最后从glibc的 strtok_r的源代码看，是strtok_r使用了这两个函数。也就是strtok_r只是包装了一下strcspn和strspn。最近看一个perf的结果，从里面有两个函数调用，不太经常见。从源代码看也没有调用这两个函数。在实际的抓取的过程中因为是libc-so里但函数，可能存在差异？32位程序和64位的还存在差异。

容器中的 /proc/sys/kernel/perf_event_paranoid 文件实际上是宿主机的 /proc 文件系统的一部分。因此，直接在宿主机上修改这个参数可以影响容器内的设置。如果想修改container上的这个文件是不可能的事。需要在host上修改这个文件。0：允许非 root 用户访问内核态和用户态事件。2：限制非 root 用户访问大多数硬件事件。1：允许非 root 用户访问用户态事件。-1：完全允许所有用户访问性能计数器。

最近在看一个路由的问题，顺便看内核代码，发现在添加IP的时候，内核会自动添加一个local route。在下面这个函数会使用fib_prefsrc；根据路由信息，如果是RTN_LOCAL的情况下。

这个错误的原因是，libpbf的相关宏定义有变动。但是perf里的代码没有更新。自己修改一些文件就好了。需要替换为：bpf_program__section_name(prog)

之前遇到过类似的问题，导致sshd-hang例子：Linux: security: 一次sshd进程读取/dev/random文件失败案例。最近搜到一个文章，说/dev/random，不在是block的。但是这个需要Redhat的注册用户才能访问详细内容。既然是不能看，就只能到网上搜一下，找到2021年的一个链接。如果不在block，用起来比较方便了，更友好一些。这个block的行为还是会对用户造成一定的困扰。

ˈænəteɪt;`ænəˌtet/ v [Tn] add notes to (a book, manuscript, text, etc) giving explanation or comment 给（书, 稿, 文字等）作注释或评注: annotated by the author 由作者加注释的.但是看修改的代码，就是将u32换成了__be32。所以这里说的注解就是用类型解释这个变量是一个big-endian，大端数据/网络数据。下面这个修改是说对这个结构体里的IP4地址做解释/注释。

最近在使用netlink替换文件读取的方式，来获取系统的arp-proxy信息。想到一个问题，内核返回回来的数据，消息的长度最大是多少？根据大数据模型的输出是，8192，是系统的一个默认返回消息的大小。如果实际内容大于8192，会分多个消息返回。如何设置更大的消息，需要使用SOL_SOCKET, SO_RCVBUF的选项设置，来设置消息大小。

下面这个实例可以看到，中间处理smp_apic_timer_interrupt的时候，来了一个smp_call_function_single_interrupt，这个优先级要比timer的高。下面这个符号代表进入中断处理函数。下面这个代表退出中断处理函数。

在这种情况下，如果线程的优先级较高，那么它在内核态执行时也会有较高的调度优先级。如果是因为中断进入内核，执行的优先级是由中断的类型（硬中断、软中断）决定的，通常比用户态或内核态的普通任务更高。软中断（SoftIRQ）或硬中断（HardIRQ）上下文：如果是中断处理导致的内核态执行（例如设备中断），那么内核的执行是基于中断的上下文，而不是用户线程的优先级。当一个高优先级的用户线程被中断并进入内核态时，接下来在内核中执行的代码的优先级并不完全依赖于用户线程本身的优先级，而是与具体的内核执行路径和上下文相关。

在 Linux 内核中，定时器（timer）并不是由一个专门的用户空间进程来管理的，而是由内核本身负责管理和调度的。内核中的定时器机制依赖于 内核定时器子系统，该子系统利用硬件的计时器中断（通常是时钟中断）来调度和运行定时器函数。Linux 内核中的定时器是由内核定时器子系统和硬件时钟中断共同实现的。ksoftirqd 和 kworker 线程会负责执行部分定时器的回调任务，但它们并不是专门为定时器而运行的用户进程。这些进程和线程虽然参与系统的定时器任务的处理，但并不是专门用来“跑”定时器的。

这个sk_tx_skb_cache的改动，对已有系统有冲击性，之前系统的内存是固定的，但是要多分配内存到socket，会导致内存不够用的情况。对于系统升级，需要预先考虑相关的影响。最近看一个问题，发现下面这个添加cache的commit，在4.18.0-283.el8版本被拿进来到RHEL8。

因为perf在解析perf data的时候，会使用当前系统的一个符号文件。相似的问题，可能会由于共享库的版不同，出现解析的偏差。需要在相同版本的内核系统，和共享库来分析perf data文件。而且当在一个版本A的机器上做的perf data文件，到另一个版本B的机器上解析，会出现符号/百分比不匹配的问题。perf的版本和内核版本是强依赖，有时候接口上可能会有些改动。

这个参数是三元值，第一个min是系统给TCP分配的最小页数；pressure，如果分配超过这个值，就进入一种pressure的状态。如果达到max，就会分配失败。对应一个全局变量：tcp_memory_pressure，记录进入pressure的jiffies。但是这里没有写进入pressure 模式，会做什么操作。这个参数的初始化，和现有内存的量有关系。关系比例是下面这个。如果大于hard limit/大于最大值会。trace event 牵扯的函数。

perf 工具可以使用 --switch-output 参数来实现对 record 生成的文件进行定期的轮转（rotate）。文件将被命名为 perf.data, perf.data.1, perf.data.2，依此类推。按文件大小轮转： 你也可以通过 --switch-output 指定文件的大小上限，达到指定大小后会进行文件轮转。这个命令每 10 秒轮转输出文件，生成文件 perf.data, perf.data.1, perf.data.2，依此类推。这将为每个 60 秒的记录生成一个新文件。