buhui912的专栏

人生总是有些意外和偶然的事情发生，就像电影霍比特人1中一样，一个偶然的晚上拜访和聚会，就让几个霍比特人在甘道夫的带领下，开启了他们的意外探险之旅。我也是这样巧合，当时已经工作快7年的我，还沉浸在嵌入式bsp开发温暖梦乡中时，突然一个意外的大厂offer打乱我的生活节奏，不过我没有甘道夫带领，全凭我之前南大富士通时的内核功底，还有多年的操作系统底层开发工作经验相陪，就这样误打误撞地开启了我的大厂os性能优化这个探险旅行。我进这个大厂之前根本没搞过os性能优化, 不过我喜欢探险，喜欢探索未知世界，就

而且手机软件开发版和稳定版是分开的，开发版多是小米内测手机用户会用，一些比较前沿或者激进点的手机功能开发，会先进开发版，这个时候还会再发现一些稳定性bug。嵌入式行业，很多特别是小公司，没有好的产品销售思路和渠道，没有优质客户，所以很多时候是在搞demo或者只能小批量的出货，也就是所谓的demo厂。如果是各个模块的单元测试阶段，每个项目组各自测试各自的模块，如果有bug，就在自己模块里面，很容易看出来的。因为产品的集成测试阶段，不再是各个子模块的单元测试了，这个时候关注的是整个os的系统稳定性。

背景借助或者研发好的分析工具对系统工程师的工作效率提升很重要系统分析优化工程师的工作职责跟app工程师有很大的不同，系统工程师需要具备cover住整个系统的能力。现在的嵌入式系统比如android的代码量有几千万行，而且系统架构搞得相当庞大复杂。搞系统性能优化的，嵌入式产品比如手机上随意出现个性能问题，可能都需要从fwk层(java代码)一直搞到内核底层，然后到存储芯片层也需要熟悉(如果是搞存储性能优化的话)。所以系统工程师，尤其是搞性能问题解决优化的，需要调研关注的代码量相当庞大，不止li

mmap_sem锁简介mmap_sem锁是进程为了保护自身虚拟地址空间不受多线程并发访问影响而设计的。多线程环境下，如果想访问进程的虚拟地址空间(比如find_vma等)，是要先持有该mmap_sem锁才能访问的，这样可以避免多线程并发修改进程vma区域造成的冲突。mmap_sem锁的一些问题总结内核mmap_sem锁设计目前存在一些问题，简单总结如下：1：保护的东西太多，范围太广了。mmap_sem目前保护:1)Rbtree of VMA，比如做find_vma()时arm

前传嵌入式系统的内存回收还是比较重要的，因为这块涉及到程序运行性能。嵌入式系统会更加关注单机性能优化，因而会更加重视系统内存回收。嵌入式系统不像互联网那种大型分布式服务器系统，他们往往内存和存储容量比较充裕，因而关注点在分布式方面，对单机性能不够重视。嵌入式系统尤其是手机这种设备，在有限的内存和存储空间因素制约下，会更加关注单机性能优化。而内存回收这块是比较重要的，因为内存回收做的不好，内存压力得不到释放，最直接的是内存压力会转化为IO压力，对系统io性能造成影响。另外也会转换为cpu压力，

背景在开发高性能软件领域，对于一名系统工程师而言，比较重要的要求是要懂内存优化。因为内存是系统宝贵的资源，软件性能跟内存是否充足是密切相关的。所以尤其是这种嵌入式终端系统中，内存有限场景下，更要熟悉系统的整机内存分布状况。知道一旦出内存问题时，该怎么去辨识和分析系统哪块内存占用有异常。并熟悉怎么去优化系统各个模块的内存占用，来为某些很耗内存资源的多媒体软件（比如相机）的性能优化工作服务。所以下面wiki, 还有另外一篇:相机场景下整机内存优化会重点讲这些东西。系统整机内存分析一个操.

内存碎片对相机性能的影响这里说的碎片是物理内存碎片，而且是外部碎片问题。先说下为什么要关注内存碎片，因为手机系统的内存碎片严重会对相机性能带来了如下不好的影响：1: 首先是相机的内存分配性能会受影响，会变得耗时很多。具体体现在相机发出大块连续物理内存(order>0)分配需求时，会受阻，会长时间陷入到direct reclaim中。相机场景下，ion和gpu内存分配, 创建子线程分配内核栈操作等都有这种连续物理内存分配需求。2: kswapd和kcompactd会异常活跃，会时常跑

一： android q的androbench数据库三项测试性能明显不如p，原因在于：p版本的文件frameworks/base/core/res/res/values/config.xml里面配置项db_compatibility_wal_supported为true。导致androbench opentest数据库时，会在文件frameworks/base/core/java/android/database/sqlite/SQLiteConnection.java函数setWalMode.

xfstests测试工具调试方法1) 针对环境搭建出错的调试方法xfstests环境搭建的入口脚本文件是kvm-xfstests/android-xfstests，可以在里面开头处加上set -x语句，这样便打开了单步调试开关，随后环境搭建的详细执行过程便会输出。根据输出信息，便可定位是环境搭建的哪个步骤出错了。2) 针对case测试出错的调试方法xfstests测试时，为了准确了解测试case对应脚本文件中，诸如_require_dm_target flakey这样的函数内部执行时是否

测试目的用xfstests工具测试手机文件系统目的有两个1：保障项目组提的性能优化changes不会对文件系统的稳定性产生不良影响。2：用xfstests工具来尽可能地多发掘一些潜在的手机文件系统稳定性问题。测试对象xfstests测试工具测试的是Android底层内核里面的文件系统（比如ext4, f2fs等）功能完整性，还有内核的整体稳定性和健壮性。测试时，会用chroot的方式，替换掉Android用户态涉及的所有程序，用自己定制的根文件系统环境进行测试。所以xfstest

背景 现在安卓手机在相机操作下，不可避免要大量消耗内存资源，同时当今手机如同电脑一样，前台相机，后台各种app进程，都会消耗内存。因而会出现相机场景下，系统可用内存不足，内存压力增加不少，对相机性能会带来严重的影响。因此需要调查相机场景下的内存优化方法。memcg调研memcg的好处：1 监控进程使用内存站在一个普通Linux开发者的角度，如果能控制一个或者一组进程所能使用的内存数，那么就算代码有bug，内存泄漏也不会对系统造成影响，因为可以设置内存使用量的上限，当到达这个值之后可..

背景平时工作中，自己不仅要有技术意识，也要有自我项目管理意识。要注意不断梳理总结出好的软件开发方面流程规范制度。这些要比工作所用到的核心技术要重要多了。好的流程规范，就像好的土壤，土壤好了，才能培育出好的产品花朵。平时用到的流程总结部署性能优化方案方面的流程首先：设计性能测试case，明确性能优化的具体实施目标和场景。这一步应该放在首要位置的，性能优化工作的重心在于挖掘并展示性能优化数据，比如提升性能具体多少。这些比较依赖于自己设计的测试case和测试工具，还有更重要的是自己发掘的具

开发目的我这边zip解压缩和io跑分类问题经常会涉及到不同存储芯片间的存储性能对比。众所周知，存储性能问题，跟存储芯片自身性能，块设备层和文件系统层的性能都有关系的。所以说搞出一款工具，能够直观地看出某性能问题对应的在存储bsp层，块设备层和文件系统层的耗时信息，是有助于解决存储性能问题的。适用场合该工具目前比较适合用来分析单线程存储性能问题。比如zip解压缩，androbench顺序读写和sqlite跑分都是属于单线程性能问题分析范畴的。因为这些测试项目在实际进行时，只有一个线程在做性能

一 文件系统缺陷导致的开机慢问题1)定位原因：文件系统做cp时，如果flush quota data不成功，就会在f2fs的cp区域设置了CP_QUOTA_NEED_FSCK_FLAG这个flag。而这个flag一旦被设置，就永远清除不了，下次开机就会做耗时的quota修复工作，这样就会导致开机慢问题出现。这个开机慢原因是原生Android的行为导致的。2)解决思路：因为fsck中的quota修复工作耗时是不可避免的，很难优化。所以只能尽量避免做开机后的quota修复工作。..

博泰做的工作事情：1：解决中断风暴的事情。出现中断风暴原因：1）imx6会固定把很多外设的中断绑在core 1上，里面有uart中断,usb设备中断。2）外设在中断控制器里面对应的自己设备的中断，有不同类型，有电平中断，上升沿下降沿中断等。当时usb的中断类型规定是在自己的设备服务程序起来后，必须对imx6的中断控制器发个回执信号，具体是写下usb相关的寄存器。如果不发回执信号的话，imx6的中断控制器就会误认为设备端那边没有接收到该中断，然后下来会不停的狂发中断到该该设备端的。这样就会有中

韩国人的这篇ijournal论文写的非常好，可以是最近几年来，诠释文件系统日志设计思想的比较好地一篇论文。以下是我做的阅读笔记：The ext4 file system uses a physical logging scheme that records the modified blocks [14], rather than logi-cal logs, which records operations.Because several of the metadata structure.

概述lowmemorykiller的作用就是当内存比较紧张的时候去及时杀掉一些对用户来说不那么重要的进程,回收内存,保证手机的正常运行。安卓平台lowmemorykiller机制演进可以描述为：从早期的Kernel space Lowmemorykiller 到UserSpace Lowmemorykiller (监听vmpressure)，再到UserSpace Lowmemorykiller (监听PSI)。内核空间LMKKernel LMK相关概念• /sys/module/lo.

引子年轻时候的我们，觉得疑难问题大都是技术方面的问题。觉得自己解个疑难高深技术问题，就很了不起似的。但是随着工作经历的不断丰富，我们会发现国内IT企业搞法，光拼技术，很容易被年轻人赶上的。因为国内知名的IT公司，无不是高强度加班。因此我们得扩大自己的视野，拓宽自己的思维，从理解和把握公司的开发业务入手，在更好地吃透公司的开发业务，更好地最大化自己团队的业务价值这方面入手，才能拉开与年轻人的差距，显示大龄工程师跟年轻人相比的独特优势。所以更大地疑难，更大地挑战在于如何更好，更快地让自己的技

引子性能问题有时候不像稳定性问题那样，出了bug, ok, fix该bug，搞定它就行了。性能问题如果涉及到文件系统自身架构方面缺陷的话，是很难解的。不过通过解这些性能问题，使我慢慢地熟悉了文件系统工作原理和架构设计，慢慢地会发现之前看不懂的内核ext4/f2fs社区那些技术邮件交流，自己现在能全部看懂了，而且还可以跟大牛搞技术合作了。问题爆出手机操作系统设计中，对前台任务的时延要求是比较苛刻的。比如Android系统，谷歌花了大精力在优化前台任务的时延，使得用户操作手机上app时，可以无卡

背景工作中常常要解决大量的Linux系统下的性能问题。这些性能问题要想高效分析解决好，其中一个基础是要对单线程工作性能有个详细完善地分析思路，能部署一个详细地性能检查check list。单线程性能影响因素分析拿手机上用户执行zip解压缩操作为例，具体做zip解压缩工作的正好是文件管理器app的AsyncTask线程。该线程的工作耗时性能直接关系到手机解压缩的性能好坏。而该线程的工作耗时分为oncputime + offcputime, 具体工作性能会受cpu ,内存和存储3大模块的影响，进

引子自己做单机存储性能优化工作已经一年多了，平时组内做的优化点需要系统总结一下了。毕竟手机存储跟分布式存储，大数据存储还有一定差别的。怎么能够找到手机存储性能优化方面的技术特性，怎么去凸显手机存储里面碰到的独特性能优化问题，有了这些需求，所以我需要写一点东西了。因为工作繁忙，只好写成了类似bbs和笔记的风格，不过虽然这样，我保证下面文字是我对手机存储性能架构方面的原创心得，网上根本搜...

背景Android平台上，是利用adeb工具来做到bcc工具在Android系统上的快速部署。一旦bcc工具在Android系统上部署完毕，我们就会很方便地利用现有的ebpf工具，进行系统开发或者调试。另外，也可以在部署好的bcc环境里面，做自己的ebpf工具定制开发。adeb简介adeb主页：https://github.com/joelagnel/adebbcc工具主页：https://github.com/iovisor/bccadeb又名androdeb, 它在Android

背景还记得之前我们开发和调试内核，面对内核错综复杂的代码，还有无数条潜在的运行路径，有点茫然不知所措。之前在内核加个代码，一不小心就会造成内核崩溃。现在好了，谷歌在Android q版本上已经集成好了bcc工具。该工具的加入，对于Android手机开发方面，无论是稳定性还是性能优化工作，都有巨大的效率提升。我们发现如果会巧妙地运用该工具的话，不仅仅是内核，驾驭整个操作系统的能力会比以前有大大的提升。bcc工具介绍简介bcc全称为(BPF Compiler Collection)，bc

背景工作中常有些这样需求，需要分析zip解压缩，androbench和应用安装等存储应用场景在不同版本，不同平台的性能差异，并且需要对这些场景做性能优化。想要做好这些需求工作，首先得对这些场景下的IO特点有所熟悉，知道这些场景会给手机施加什么样的workload。这一步做好后，对下来无论是调研存储性能优化方案，还是分析这些场景对应的性能jira都会有很大帮助的。IO workload解析解析工具介绍由于部分app代码不开源（比如androbench等），并且就算代码开源，由于上层代码

androbench跑分对应IO特性分析在博文：手机IO workload解析里面已经指出androbench测试时，产生的IO都是direct IO。因为对手机反复androbench测试多次，根据测试log和代码分析，结论是：Android跑分测试时，direct io对应的内核路径只有__blockdev_direct_IO里面会submit 大量bio的，该路径下其他函数仅仅submit了很少量的bio，这些很少量的bio不影响跑分测试结果的.支撑上面结论的原因是： 1)...

背景Linux系统下的性能问题不太好解决，尤其是存储相关的问题。工作中面临这些的性能问题是比较多的，大部分是用户反馈的。为了能及时高效地解决性能问题，迫切地需要对性能问题解决方面有个系统的，深入的探索。性能问题特点性能问题跟稳定性问题相比，还是有很多自己独特的地方的。总结起来，性能问题有如下几个特点：1：性能问题的评判标准多带有主观性的稳定性问题基本上是系统出现bug了，导致某方面功能不正常。那这个肯定是必须解决的，而且评判标准也比较简单，就是解决后，该bug不会再出现了。性能.

背景存储是高风险作业。一旦有文件系统相关问题后，发生内核panic，手机进入ramdump这还影响不算大。如果导致用户文件数据损坏的话，就会造成比较大的影响。以前对文件系统源码修改后，由于没有一款专门针对文件系统的测试工具，所以只跑mtbf或者kasan的话，文件系统的稳定性问题是无法被有效地发掘的。现在有了xfstests, 文件系统的稳定性方面可以得到强有力的保障。xfstests保障文件系统稳定性方面的见证：1：我这边用xfstests generic/204号case 测试And

背景 最近很多项目组报文件丢失，文件被篡改等bug单子。所以想做个文件监控方案，可以监控某些目录下面或者文件的异常操作，做到能及时找到文件异常操作的元凶和异常操作的时间点，并及时输出log日志。 这样如果推到用户那边，用户只需要定制一些监控事件，push到sdcard根目录下面，然后开启监控，就可以以后不用受开关机影响，永久的持续性的监控文件异常操作了。方案设计 这种监控方案设计时，无非需要考虑以下几点： 1：是否影响手机性能 2：通用性......