happyAnger6的专栏

性能分析—内存篇page_fault分析步骤1.sar -B 1整体分析,重点关注fault/s# sar -B 1Linux 5.4.0-92-generic (zhangxa-Precision-3650-Tower-docker) 01/17/22 _x86_64_ (16 CPU)11:35:37 pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff

核心替换层— 接入点（特性注册 + ONNX 导出）当前方案为方案 A：纯 PyTorch 模块替换 + ONNX 原生算子图重写，零 plugin。

当前已对π0.5做了较多优化,后续的优化方向roadmap,希望有更多感兴趣的同学start并参与。

当前：CuTe DSL Python kernel 源码。：AOT 编译，导出 C ABI 头文件、目标文件和静态库。cpp/：C++ Runner + TensorRT Plugin，链接 AOT 静态库并生成 plugin.so。：Python/ONNX 导出，把模型里的 attention 映射成 TRT plugin op。整体流程如下：fill:#333;important;important;fill:none;color:#333;color:#333;important;

以cutlass中为例，说明 kernel 内两条软件流水线的配置、与的关系，以及 CuTeDSL / CUTLASS C++ / 裸 CUDA 的对应关系。

在jetson Thor上使用完成了π0.5模型的推理部署。

对pi05的llm模型进行nvfp4量化后,精度下降明显.

类别能力举例Aya 侧常见切入点执行与调度exec/fork、调度延迟、运行队列系统调用延迟分布、敏感调用审计tracepoint（raw 或 BTF）、kprobe文件与块 I/O读写路径、延迟、vfs 层事件网络包过滤与统计、重定向、连接跟踪XDPcgroup_skb、sockops/sk_msg 等内存与延迟页故障、分配路径（需合适钩子与内核支持）用户态对进程/共享库打点采样与剖析CPU 周期、栈采样（与 perf 协同）perf_event等程序类型安全策略。

使用矢量化加载可以减少指令总数，降低延迟，并提高带宽利用率.使用矢量化加载的最简单方法是使用CUDA C++标准头文件中定义的矢量数据类型，如int2、int4或float2、float4.这些类型表示打包在一个数据单元中的多个值。您可以通过C++中的类型转换轻松使用这些类型.例如，在C++中，你可以使用reinterpret_cast<int2*>（d_in）将int指针d_in重写为int2指针，该指针将一对“int”值视为一个单元。您还可以使用结构生成矢量化加载，只要该结构的大小是两个字节的幂。

10亿参数模型：需约1-10 PetaFLOP/s-days（等效1万亿次浮点运算持续1天）千亿参数（如GPT-3）：约3,000-5,000 PetaFLOP/s-days万亿参数模型：超过50,000 PetaFLOP/s-days。

BPF CO-RE的目标是帮助BPF开发人员以简单的方式解决简单的可移植性问题（如读取结构字段），并使其仍然有可能（如果不是微不足道的话，也是可以容忍的）解决复杂的可移植问题（如不兼容的数据结构更改、复杂的用户空间控制条件等）。这允许BPF开发人员停留在“编译一次–到处运行”的范式中。这是通过组合几个BPF CO-RE构建块来实现的，如本篇文章的内容所述：vmlinux.h消除内核头文件依赖字段重定位（字段偏移、存在、大小等）使从内核提取数据变得可移植。

BPF CO-RE的目标是帮助BPF开发人员以简单的方式解决简单的可移植性问题（如读取结构字段），并使其仍然有可能（如果不是微不足道的话，也是可以容忍的）解决复杂的可移植问题（如不兼容的数据结构更改、复杂的用户空间控制条件等）。这允许BPF开发人员停留在“编译一次–到处运行”的范式中。这是通过组合几个BPF CO-RE构建块来实现的，如本篇文章的内容所述：vmlinux.h消除内核头文件依赖字段重定位（字段偏移、存在、大小等）使从内核提取数据变得可移植。

我们可以利用这个offcputime来分析实际环境中因为各种原因造成的进程阻塞及卡顿问题.

堆栈推导一般用于coredump文件分析，火焰图制作等场景.了解其原理,有助于帮助我们分析异常问题，以及优化火焰图的制作流程,减少不完整栈情况的出现.堆栈推导有两种常见方式:fp与dwarf. 本篇文章介绍这2种堆栈推导方式的原理及适用场景.

欢迎参与deepE项目。

因为学习的书比较老,所以libbpf我们要使用v.8.0.0版本。

linux对每个磁盘或分区都维护有一个请求队列,i/o算法会进行操作的合并重排等操作以优化性能。

这里的延迟是１.1中, 2和3操作之间的延迟。即从内核将i/o操作提交给块设备到块设备完成操作通知内核软中断处理的耗时.linux对每个磁盘或分区都维护有一个请求队列,i/o算法会进行操作的合并重排等操作以优化性能。i/o结束时,分别统计i/o请求在队列中的等待时间和i/o操作块设备的延迟时间.显示进行i/o操作的程序，操作的磁盘扇区，读/写操作, 字节数，以及延迟。获取当前放入i/o request_queue的时间，并放入map中。获取当前提交块设备i/o请求的时间，并放入map中。

ProtoZero是一个零拷贝，零分配，零系统调用的protobuf序列化库,主要用于在Perfetto里实现跟踪记录.

因此，我们只需在2.1.1时记录线程的tid和时间, 在2.1.2时根据tid取出2.1.1时记录的时间并与当前时间做差值，即可得到调度延迟.然后我们用bcc前端结合上面的ebpf程序实现延迟数据获取并记录perfetto支持的json的代码.perfetto支持proto与json等多种格式，为了简化我们的实现难度,我们使用json格式.这里我们只需要研究一下perfetto的数据格式,并按照其格式存储即可.我们可以跟踪线程从放入就绪队列到实际被选中并获得CPU的过程。这里要注意，我们检测系统是否支持。

概述通过本文,你将了解到以下内容:fastdds的调试统计功能如何使用fastdds的调试统计功能有什么问题如何使用USDT(systemTap) + ebpf对fastdds调试统计功能进行改造,以实现动态开关调试功能并实现高性能.fastdds statistics官方文档及说明https://fast-dds.docs.eprosima.com/en/latest/fastdds/statistics/statistics.html已知bughttps://fast-dds.do

使用ros2实现的节点，订阅了较多的topic数量(70个左右), 节点cpu使用率明显升高使用perf观察火焰图，executor耗时较多.在ros2 rclcpp的github上搜到确实有一个相关的issue.

本文通过一个TCP重传优化的实际问题，详细讲解问题的分析、定位、优化过程。/procbcc。

其实我们可以针对不同类型的问题，制作相应的火焰图。因为不同cpu上linux处理page_fault的入口可能不同，所以我们先用bpftrace工具查找一下对应的函数。使用TCMalloc后可以使用火焰图和pidstat再次确认内存使用情况。如果改头善不明显，可能要针对里程内存的使用特点，对TCMalloc进行参数调整或者使用其它内存分配器。可以看到进程每秒的page_fault次数有几万次，数量还是很高的，有很大优化空间.使用TCMalloc让进程尽可能的缓存使用的物理内存，而不是频繁的交还操作系统。

1.6万字bpf正如上文中提到Linus对epbf的评价ebpf的强大的可编程性几乎可以最大程度地的满足我们性能分析、追踪、安全等各种需要。既然类似于一门编程语言，我们就可以从学习一门编程语言的角度来学习它。看看ebpf都提供给我们哪些编程便利.

它提供了数据链路层的接口,可以在数据链路层发送和接收数据.如果网卡支持混杂模式,所有的数据包都可以被接收,即使这些数据包的目的地址是其它主机.安全是因为ebpf程序需要经过内核中验证器的验证,它可以进行静态代码分析,拒绝可能crash,hang或者对内核有负作用的代码.这些过滤指令实际上是由内核中运行的虚拟机执行的,这个内核中的虚拟机就是BPF的实现核心.这种验证模式和沙箱机器不同,沙箱的运行环境是有限制的,且对执行的程序没有了解能力.,程序可以关联到内核的多种hooks,并在事件触发时运行.

既然clock_gettime可以通过vdso,为什么异常系统上还会有这么多系统调用呢?

很多东西的学习都开始于一个’hello world’, ebpf也不例外。实验环境: ubuntu 20.04。

表示与轮询表中其他设备相比，该设备的相对重要性。网络驱动程序对特定于设备的中断设置了一个处理例程，因此每当该中断被引发时（即分组到达），内核都调用该处理程序，将数据从网卡传输到物理内存，或通知内核在一定时间后进行处理。由于下一个分组也通过IRQ通知，如果前一个分组的IRQ尚未处理完成，则会导致问题，高速设备通常就是这样。在从 napi_struct 的容器获得特定于设备的信息之后，调用一个特定于硬件的方法（这里是。么不利之处：在没有分组还需要处理时，将停止轮询，设备将回复到通常的IRQ驱动的运行方式。

当CPU、memory或IO设备处于竞争状态，业务负载会遭受时延毛刺、吞吐量降低，及面临OOM的风险。如果没有一种准确的方法度量系统竞争程度，则有两种后果：一种是用户过于节制，未充分利用系统资源；另一种是过度使用，经常性面临业务中断的风险。psi特性能够识别和量化资源竞争导致的业务中断，及其对复杂负载乃至整个系统在时间上的影响。准确度量因资源不足造成的生产力损失，有助于用户基于硬件调整业务负载，或基于业务负载配置硬件。

在编译内核时打开或者在启动参数中增加这样统计信息是在采样周期中收集的。其中number行分别是发生stalled的cpu上的硬中断，软中断，和上下文的切换次数cputime行的前三列分别是硬中断，软中断和任务消耗的cpu时间,单位为ms.最后一个数字是统计的周期时间(ms).因为用户态的任务通常不会引起RCU CPU stalls,所以任务通常是内核任务,这也是为什么只统计system cpu的原因.

然后在流程2读取udp缓冲区时(__skb_recv_udp)时取出1中记录的skb时间，并与当前时间做差值得到延迟.为了分析udp数据通信中端到端的延迟,我们需要对整个通信链路的每个阶段进行监控,找出延迟最长的阶段.2和1之间可能由于调度等造成延迟，我们写一个bcc程序对指定接收端口和延迟大于某个值的情况进行监控。我们在流程1放入udp缓冲区时(udp_unicast_rcv_skb),记录此skb的时间。1.数据包到达本机后，由软中断处理程序将数据包接收并放入udp socket的接收缓冲区。

使用"default_external_unicast_locators"置空关闭默认的单播udp端口。默认情况下,FastDDS会对本机的topic使用共享内存,并默认开启一个单播udp端口接收数据.因此我们使用"useBuiltinTransports=false"关闭默认的共享内存通道。并配置一个组播地址用于接收数据，并通过代码在创建data_reader时使用它.

BPF学习之性能分析1. 概览1.1.目标性能分析前我们需要先明确目标,有的放矢.明确了目标后,进一步的分析工作就有了上下文,不至于跑偏.一般来说,性能分析的目标是改进用户最终体验和降低运行成本.有了目标,最好能将其进行量化:这种量化能够表明是否已经达到优化的目标,还可以定义离目标的差距有多远.可测量的指标:延迟: 多久可以完成一次请求操作,通常以毫秒为单位.速率: 每秒操作或请求的速率.吞吐量: 通常指每秒传输的数据量,以比特(bit)或者字节(byte)为单位.利用率: 以百分比形