4f0f05ce26d5a43eed29a6768e1af61a411052e7c82e8ce77d6bea88f8a3ca21b842002bb2faee4fb8cc177830b3a670bf0ab1e1f5bb2d01a4b650ec390a261c8681a2f20272a897c4dacb05ea1f38a7d303a1ef944d2225674647138987f7faed531ba671a234502bb61179c2e4c3904c2d4a19b20f965a0bbd22500b34695e60db4fa778b99ed120e2da8d7df7a957c0b6475fa943c163965faa3c1750873579a489a8d86fe06683de48113c769587f7e88b27da831f643c019128fabf2a59348ecb7b07d483ddabcc3e6576a7a949a496378822627c5dde0da2313c360f62a802068e128f3b50bd58db52d13bc80cb4974614adb969835 ...
一、安装python工具前往网站(https://www.python.org/downloads/)下载python安装包,python >= 3.6.8即可
安装python工具到一个目录,比如:C:\Python36
进入到C:\Python36\Scripts目录中,使用pip指令安装库12pip install psutilpip install pyelftools
二、获取linux ramdump parser工具2.1 Opensourcevendor/qcom/opensource/tools
12git clone e https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/tools.gitgit checkout -b opensource-tools.lnx.1.0 remotes/origin/opensource-tools.lnx.1.0
2.2 proprietaryvendor/qcom-proprietary ...
Linux内存管理
未读
0. 前言简单来说,在使用zoned page frame allocator分配页面时,会将可用的free pages与zone的watermark进行比较,以便确定是否分配内存。同时watermark也用来决定kswapd内核线程的睡眠与唤醒,以便对内存进行检索和压缩处理。
回忆一下之前提到过的struct zone结构体:
1234567891011121314151617181920212223struct zone { /* Read-mostly fields */ /* zone watermarks, access with *_wmark_pages(zone) macros */ unsigned long watermark[NR_WMARK]; unsigned long nr_reserved_highatomic; ....}enum zone_watermarks { WMARK_MIN, WMARK_LOW, WMARK_HIGH, NR_WMARK};#define min_wmark_pages(z ...
4f0f05ce26d5a43eed29a6768e1af61a411052e7c82e8ce77d6bea88f8a3ca21b842002bb2faee4fb8cc177830b3a670bf0ab1e1f5bb2d01a4b650ec390a261c8681a2f20272a897c4dacb05ea1f38a7d303a1ef944d2225674647138987f7faed531ba671a234502bb61179c2e4c390a6170156d47a2c38944cde955a292aa41176644771a76db7fa5ac62df64df65f75d986571b0b3737d7a5bfcd829c5a75e5534bce71d7ebbbabf20590921557e3f76e840e66a8487b99342432822236f502825a19ad97ac8d95015779ea0ca348a06995d6e5f940cf1f0cdc1a46aec1c84e1c0e91a0a9bd4bd0de435fe3e29171b21b650fb59b30a0d ...
Linux内存管理
未读
0. 前言在上一篇文章中我们分析了__alloc_pages中的get_page_from_freelist,也就是快速分配部分。这个函数会根据分配掩码和分配order进行快速分配,若快速分配过程并不能分配到合适的内存时,则会进入慢速分配的过程。
本文紧接前文继续分析__alloc_pages函数,继续剖析buddy内存分配的另一个过程:慢速分配
1. __alloc_pages_slowpath当快速路径分配内存失败时,内核会调用这个函数来尝试各种方法(如回收内存、整理内存碎片、甚至启动 OOM 杀手)来成功分配内存
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411 ...
一、什么是RCU?RCU(Read-Copy-Update,读-复制-更新)是一种 高效的内存同步机制,用于在多核、多线程环境下,解决读写并发问题。它特别适合读多写少的场景,可以显著提高系统的并发性能和效率。RCU 的核心思想是:
读操作不加锁:读操作可以在不阻塞的情况下完成,因为它不会直接修改数据。
写操作创建副本:写操作在更新数据前,会创建原数据的副本,并对副本进行修改。
延迟释放旧数据:在确保所有读操作完成后,旧数据才会被安全地释放。
通过这种机制,RCU 实现了高效的读写操作分离,避免了传统锁机制可能引发的性能瓶颈。
二、什么是RCU stall?当 RCU 子系统检测到以下任一问题时,会触发 RCU Stall:
RCU Grace Period 未结束: RCU 的宽限期(Grace Period)超出预期时间,可能是某个 CPU 或任务未能退出其 RCU 临界区,导致 RCU 回调无法执行。
RCU Callback 堆积: RCU 的回调函数无法按时处理,可能是由于系统负载过高或 CPU 长时间未运行相关线程。
长时间调度延迟: 某些任务或内核线程被阻塞,导 ...
Linux内存管理
未读
0. 前言在前一文[linux内存管理] 第19篇 buddy分配器基础知识以及分配器api接口中,对buddy分配器的基础知识做了简单的介绍,包括涉及到的分配掩码、分配标志、分配入口函数、释放入口函数,而buddy分配的工作是分为快速分配和慢速分配两种的
快速分配:指现有的buddy系统中的free_list中有足够的内存,可以满足申请的需要,或者是通过简单的迁移就能达成申请内存的目的。
慢速分配:指中间经历了内存碎片整理、内存回收、OOM等耗时的操作,而这些操作只是为了让buddy系统获得足够的空闲内存。
注意:
正如前文我们所提到的分配函数alloc_pages、alloc_page以及get_zeroed_page函数追本溯源之后,可以知道都可以溯源到alloc_page,所以本章将会以alloc_pages函数开始剖析buddy的分配算法
1. alloc_pages函数剖析1234567891011121314151617181920212223static inline struct page *alloc_pages(gfp_t gfp_mask, unsigned ...
1. 前言在工作中,经常会遇到由于越界导致的各种奇怪的问题。为什么越界访问导致的问题很奇怪呢? 在工作差不多半年的时间里我就遇到了很多越界访问导致的问题(不得不吐槽下IC厂商提供的driver,总是隐藏着bug)。比如说越界访问导致的死机问题,这种问题的出现一般需要长时间测试才能发现,而且发现的时候即使有panic log。你也没什么头绪。
这是为什么呢?假设驱动A通过kmalloc()申请了一段内存,不注意越界改写了与其相邻的object的数据(经过我之前一篇SLUB的文章分析,你应该明白kmalloc基于kmem_cache实现的),假设被改写的object是B驱动使用的,巧合B驱动使用object存储的是地址数据,如果B驱动访问这个地址。那么完了,B驱动死了,panic也是怪B驱动。试想一下,这块被改写的object是哪个驱动使用,是不是哪个驱动就倒霉了?并且每一次死机的log中panic极有可能发生在不同的模块。但是真正的元凶却是A驱动,他没事你还不知道,是不是很恐怖?简直是借刀杀人啊!
当然,越界访问也不一定会死机。之前就遇到一个很奇怪的问题。有两个全局数组变量(用作存储字 ...
本章建议先看[linux内存管理] 第020篇 Linux内核slab内存的越界检查——SLUB_DEBUG的原理剖析
1. linux ramdump parser解析dump查看死机原因,是Non secure wdt
123456789CPU |Reset Reason |Reset Count0 |0x00000000 (TZBSP_ERR_FATAL_NONE ) |0x000000001 |0x00000001 (TZBSP_ERR_FATAL_NON_SECURE_WDT ) |0x00000001 // 报错2 |0x00000000 (TZBSP_ERR_FATAL_NONE ) |0x000000003 |0x00000000 (TZBSP_ERR_FATAL_NONE ) |0x000000004 |0x00000000 (TZBSP_ERR_FATAL_NONE ) |0x000000005 |0x00000000 (TZBSP_ERR_FATAL_NONE ) |0x000000006 |0x00000000 (TZBSP_ERR_FATAL_NO ...
0. 前言内核稳定性问题复杂多样,最常见的莫过于“kernel panic”,意为“内核恐慌,不知所措”。这种情况下系统自然无法正常运转,只能自我结束生命,留下死亡信息。诸如:
“Unable to handle kernel XXX at virtual address XXX”“undefined instruction XXX”“Bad mode in Error handler detected on CPUX, code 0xbe000011 – SError”……
这些死亡信息是系统在什么状态下产生?如何产生?以及如何处理?
本文主要就是从这三个方面介绍,在看本章前,请确保已经看完aarch64异常模型以及Linux arm64中断处理
1. 异常处理流程本节案例参考[Android稳定性] 第015篇 [问题篇] Unable to handle kernel NULL pointer dereference的这个异常。
panic的异常如下:
1234567891011121314151617181920212223242526272829303132333435 ...