ftrace

上个礼拜我就想喷eBPF了，由于周末时间实在太紧，就准备拖延一周，但还是立了个flag，先发了个朋友圈： ebpf就像牛皮藓一样，已经遍布在linux内核的各个角落，每个调用点都看上去很随意，毫无规划，让人觉得好像自己觉得哪里需要这么一个调用点并不很难… 但实际上如果你真的去尝试在某处加一个ebpf调用点时，就会觉得这件事和清除牛皮藓的过程非常类似，修改散落在各个目录的多个文件，还得重新编译，大概率失败，还要重新做一次，很难一次做干净，当你好不容易成功了，会有一种“不过如此”的嗟叹… 我曾将ebpf比做扩散的癌细胞，这个比喻没有给人密集恐惧的效果，所以我换成了牛皮癣。该存在ebpf调用点的地方一个也没有，没必要ebpf的地方到处都是，这些点还在持续增加，迄至5.11内核，ebpf已经有大三十个点了，依然在毫无规划地疯长着… eBPF是个创新，但人们明显狂热过度了，ebpf增加调用点也过于随意，太业务导向了，损坏了内核的内聚性，远远比不上当初netfilter的五个hook点以及qdisc这种经过良好设计的机制，另外还有一个问题，netfilter的五个hook点上如果部署了ebpf点，其实就能解决大部分性能问题，然而直到现在都没有，感觉是社区矫枉过正了，真的彻底把netfilter当成了旧时代的象征，把马杀掉的同时，轮子也不要了 人们都像虫子一样在这里你争我抢，吃的都是良心

安卓高面试知识整理 0.0Android 四大组件：这是一份全面 & 详细的Activity学习指南 https://blog.csdn.net/carson_ho/article/details/107012652 0.1手把手带你清晰梳理自定义View的工作全流程！ https://blog.csdn.net/carson_ho/article/details/98477394 1.activity启动流程 Activity启动过程简要介绍 无论是通过点击应用程序图标来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都要借助于应用程序框架层的ActivityManagerService服务进程。在前面一篇文章Android系统在新进程中启动自定义服务过程（startService）的原理分析中，我们已经看到，Service也是由ActivityManagerService进程来启动的。在Android应用程序框架层中，ActivityManagerService是一个非常重要的接口，它不但负责启动Activity和Service，还负责管理Activity和Service。 Android应用程序框架层中的ActivityManagerService启动Activity的过程大致如下图所示： 在这个图中

什么是Systrace Systrace 是 Android4.1 中新增的性能数据采样和分析工具。它可帮助开发者收集 Android 关键子系统（如 SurfaceFlinger/SystemServer/Kernel/Input/Display 等 Framework 部分关键模块、服务，View系统等）的运行信息，从而帮助开发者更直观的分析系统瓶颈，改进性能。通常使用 systrace 跟踪系统的 I/O 操作、CPU 负载、Surface 渲染、GC 等事件。 Systrace 的功能包括跟踪系统的 I/O 操作、内核工作队列、CPU 负载以及 Android 各个子系统的运行状况等。在 Android 平台中，它主要由3部分组成： 内核部分 ：Systrace 利用了 Linux Kernel 中的 ftrace 功能。所以，如果要使用 Systrace 的话，必须开启 kernel 中和 ftrace 相关的模块。 数据采集部分 ：Android 定义了一个 Trace 类。应用程序可利用该类把统计信息输出给ftrace。同时，Android 还有一个 atrace 程序，它可以从 ftrace 中读取统计信息然后交给数据分析工具来处理。 数据分析工具 ：Android 提供一个 systrace.py（ python 脚本文件，位于 Android SDK目录

前面谈了kprobe的原理，其实uprobe也差不多： https://blog.csdn.net/dog250/article/details/106520658 那么return probe如何实现呢？ 我们知道，hook一个函数的起始位置非常容易，拿函数名当指针，直接修改成0xcc或者别的什么call/jmp即可，而hook一个函数的结束就没有这么简单了： 函数大小不容易计算。 函数可以在任意位置调用return。 怎么办呢？ 很简单，只要执行流到了函数里面，直接取RSP寄存器指示的地址即可，它就是函数返回的地址，hook这个地址，就OK了。 于是，方法也就有了： 在函数开头打int3断点(也可以ftrace，但这里仅谈int3)。 在函数调用时的int3处理函数中获取stack上的return address。 将return adress替换成int3的address(也可以用单独的函数)。 在return address的int3处理函数中调用return probe函数。 恢复正常流程。 如下图所示： 下面是一个示例程序： # include <stdio.h> # include <sys/mman.h> # include <signal.h> // sigframe的RIP偏移 # define PC_OFFSET 192 // sigframe的RSP偏移 #

你好！这里是风筝的博客， 欢迎和我一起交流。 ALT+SYSRQ组合键是Linux调试的一种手段，即使在系统死机、panic、卡住等情况，只要系统还能响应中断，那么SYSRQ就派上用场了（比如触发crash查看系统当前在干啥），具体的使用情况可以参考内核文档里的详细描述：Documentation/sysrq.txt note：SYSRQ键也就是键盘上的Print Screen键. 使用SYSRQ组合键需要在内核开启配置：CONFIG_MAGIC_SYSRQ 可以通过在系统中使用 cat / proc / sys / kernel / sysrq 查看sysrq是否开启，sysrq值对应： in /proc/sys/kernel/sysrq: 0 - disable sysrq completely 1 - enable all functions of sysrq 1 - bitmask of allowed sysrq functions (see below for detailed function description): 2 - enable control of console logging level 4 - enable control of keyboard (SAK, unraw) 8 - enable debugging dumps of

刚毕业那会儿，VC6学习MFC，总得来点儿好玩的东西才能继续下去，毕竟不是科班出身，得完全靠意义去驱动…那个时候认识了键盘钩子，鼠标钩子之类： https://blog.csdn.net/dog250/article/details/5303610 这种方法貌似还可以盗号…只是QQ早就解决了这个问题。 不说Windows钩子了，说说Linux系统中如何监控键盘输入，这简直太简单了。 关于Linux终端，详见： https://blog.csdn.net/dog250/article/details/78766716 接下来我们就知道如何搞了： hook n_tty_receive_char函数 我们先看下实际效果： stap - e 'probe kernel.function("n_tty_receive_char") {printf("%c ", $c);}' 我们看看会发生什么，在随便一个ssh终端敲入pwd，ls等命令，stap回显如下 l s p w d 这里只是演示，下面我们来实现它。 很容易想到得是，直接将n_tty_receive_char函数的开头5个字节的Ftrace caller改成一个call stub即可，一般的stap也都是这么干的，然而我们实际看一眼： crash > crash > dis n_tty_receive_char

Linux系统不是可以有lsmod枚举所有内核模块吗？procfs不香吗？干嘛还要费事从/dev/kmem里去枚举？ 其实，Linux是后来的事了，在最初的UNIX时代，像ps之类的枚举进程的，都是从/dev/kmem里扫描出来的，这就是 一切皆文件 ，后来的Linux内核很不恰当地拓展了procfs，将乱八七糟的东西都往里面塞，像modules，filesystems，vmallocinfo之类，这些明明不是进程，全部扔进去了，这并不合适，但就是因为这是Linux内核，所以什么都是对的！ 当然，Linux也保留了/dev/mem，/dev/kmem这两个极其特殊且好玩的文件： /dev/mem：映射系统所有的物理内存。 /dev/kmem：映射系统所有的内核态虚拟内存。 再后来由于/dev/kmem暴露的权限过大，存在安全隐患，所以一般的内核都封堵了这个字符设备，仅仅保留了/dev/mem，并且还是在受限的情况下： # CONFIG_DEVKMEM is not set CONFIG_STRICT_DEVMEM = y 本文我们就展示一下如何通过扫描/dev/kmem来枚举所有的内核模块。 什么？不是说CONFIG_DEVKMEM被禁用了吗？好办！重新移植过来便是了，并且，我重新移植的版本还能支持vmalloc空间的映射呢。 代码如下： // kmem.c # include

相关推荐： https://www.forlinx.com/article_view_261.html 一、实时系统分类 实时系统可以分为硬实时（Safety-Critical，低延时，比如几十个us内）和软实时（几百个us~几个/几十个ms)，硬实时通常跟高确定性、可靠性要求同时出现，如果达不到，可能会造成重大生命或者财产损失，比如说航天飞控、汽车制动系统、精密仪器等都有较高的硬实时要求。对于软实时，可靠性要求没那么高，即使出现了延迟，造成的损失可控，比如说音频失真，视频不顺畅。 二、已有方案 Linux 本身已经有硬实时的方案，比如来自风河的 RT Linux，或者西班牙一家研究所的 XtratuM + PartiKle，还有其他的比如 Xenomai，RTAI 等。另外，内核官方还有完全抢占内核（Preempt-RT Linux）的支持，这个在某些情况下也达到了硬实时要求，改补丁现在有OSADL维护。 然后就是各种优化，包括驱动（irq, preempt disable), spin lock 等使用，中断函数线程化，mdelay 替换为 usleep_range() 等。优化时需要用到很多工具，比如 Ftrace, Perf, Cyclictest, Oscilloscope 等。 硬件本身的低延迟设计、可靠性设计等也会严重影响系统的实时性，比如说 ARM Cortex A

3 月，跳不动了？>>> 如果遇到 MySQL 慢的话，你的第一印象是什么，如果MySQL 数据库性能不行，你是如何处理的？ MySQL 慢怎么办 如果遇到 MySQL 慢的话，你的第一印象是什么，MySQL 数据库如果性能不行，你是如何处理的？ 我咨询了一些同行, 得到了以下反馈： 第一反应是再试一次 第二个反应是优化一下 SQL 第三个反应是调大 buffer pool，然后开始换硬件了，换一下 SSD 最后实在不行了找个搜索引擎搜索一下“MySQL 慢怎么办”。 如果大家用的是国内的搜索引擎的话，搜索引擎会推荐某某知道或者某某乎, 推荐一些 MySQL 调优经验, 调大参数 A, 调低参数 B, 诸如此类，类似的网站能告诉你 MySQL 慢怎么办。 我们来分析一下这些现象背后隐藏的意义： 如果再试一次能够成功的话, 意味着你可能碰到了不可复现的外界因素的影响，导致 MySQL 会慢。 如果优化 SQL 能解决，就意味着 SQL 的执行复杂度远远大于它的需求复杂度。 如果调大 buffer pool 能解决，就意味着 MySQL 碰到了自身的某些限制。 如果换 SSD 能解决，那么意味着服务器资源受到了一定的限制。 如果需要搜索引擎，意味着调优这事已经变成了玄学。 本文向大家分享我对 MySQL 慢的诊断思路，以及向大家介绍系统观测工具。 MySQL 慢的诊断思路 MySQL