Linux Stuff

Agenda 1.   Run 基本结构 2.   主要算法 a)      Allocate b)      Free 正文 ROS memory allocator 是 Android ART virtual machine 中 GC 的一个内存分配器。 ROS 是 Run-of-Slots 的缩写。 在 ROS allocator 中，分配的都是虚拟地址区间（具体的物理内存什么时候分配是由 kernel 中的 page fault 来负责的）。 ROS allocator 的基本分配单元是 slot 。 slot大小 从 16Bytes 到 2048Bytes ，分别是 16,32,48,… n*16,512,1024,2048. 不同大小的 slot 对应不同种类的 Run ，换句话说，一种 Run 提供大小相同的 slot. 一共有 34 种 Run. 一 , Run 的基本结构 一个 Run, 可以分为两大部分，分别是 Run header 和 Data Area 。如下所示： Run header 里面包含了 ∙             Magic number: Debug 相关 ∙             Size_bracket_idx_: 表示了该 Run 中的 slot 的 size 是多大。比如 Size_bracket_idx_ 是 10 ，那么该 Run 中的 slot 的 size 是（ 10+1 ） *16=176 Bytes. ∙             Is_thread_local: 表示了该 Run 是否是 Thread local area. ROS allocator 规定每个线程都会持有一组 Thread local Ru...

ARMV8的spec.对device memory新引入了3个概念，分别是：Gathering, Reordering和Early Write acknowledge.下面从软件工程师的角度去阐述这三个概念。 Gathering The Gathering attribute determines whether it is permissible for either: • Multiple memory accesses of the same type, read or write, to the same memory location to be merged into a single transaction. • Multiple memory accesses of the same type, read or write, to different memory locations to be merged into a single memory transaction on an interconnect. 当某条load/store指令在pipeline的access memory阶段，发生cache miss(对于non-cacheable的memory就直接跳过，不过对于device memory一般都是non-cacheable的)后，需要将access memory请求发到总线上(例如AXI总线)，通过AXI总线访问device memory，这个通过总线访问memory的过程被称为一次transaction. 为了优化性能考虑，在core内，会引入一个Buffer, 当发生一个access memory请求后，会将这个请求信息丢到Buffer中，若某条指令和上一条指令共享同一个cache line或者是访问同一个地址,那么，该条指令便不会再向总线发送transaction了，它share上一条指令 读到buffer中的结果。这个share的过程称为gathering. 读到buffer中的数据，如果是cacheable的，会在某个时间内腾到cache中。 Reordering reordering也是针对device memory的transaction, that is, 某个devic...

DMB: Data memory barrier 理解DMB指令，先看下面例子，在core 0和core1上同时跑两个不同的指令（如下表所示） core 0 core 1 Write A; Write B; Load B; Load A; 这里core0在执行两个指令，写A B两个值的时候， 可能会发生乱序 也可能 Write A时发生Cache Miss ，那么就会导致在cache中 A的最新值更新慢于B的最新值。于是在core1中的指令Load B就会拿到新值，而Load A 就会拿到旧值。如果A与B有相互关系的话，便可能产生死锁等问题。这里有一个典型的例子： https://lkml.org/lkml/2012/7/13/123   于是，就有了下面的解决方法： core 0 core 1 Write A DMB; Write B Load B Load A 在core0所执行的两条指令之间加入一个DMB. 这样，若core1在Load B时，拿到了最新值。那么Load A 也一定拿到了最新值。这就是DMB的作用： DMB前面的LOAD/STORE读写的最新值的acknowledgement在时间上一定先于DMB之后的指令。 DSB 和DMB容易混淆。他们的区别在于：DMB可以继续执行之后的指令，只要这条指令不是内存访问指令。而DSB不管它后面的什么指令，都会强迫CPU等待它之前的指令执行完毕。其实在很多处理器设计的时候，DMB和DSB没有区别（DMB完成和DSB同样的功能）。他们以及ISB在arm reference中的解释如下[1]： A  Data Synchronization Barrier (DSB)  completes when all instructions before this instruction complete. A  Data Memory Barrier (DMB)  ensures that all explicit memory accesses before the DMB instruction complete before any explicit memory ac...

It’s known that there are many tools to debug crash Linux for X86 architecture, such as kdump, LKCD, etc. Although many debugging tools claim that they could support ARM architecture, they are unstable. Is there a reliable method for ARM SOC? Yes, this blog will show a stable method for debugging ARM Linux. There is a premise that you could dump the memory snapshot by some assistive hardware tools when crash happen. This premise is easy for ARM SOC company. This method for debugging ARM Linux is to compose a crash image and analyze the crash kernel with the aid of Crash Utility. Now I will explain this method by step. 1.        Build Linux Kernel for ARM SOC. Please make sure that the feature kexec and debug info are enable. ·          Boot options  --->  ·          [*] Kexec system call (EXPERIMENTAL) ·       ...

crashnote contains register status when crash happens. In kernel, this data is stored “note_buf_t __percpu *crash_notes”. include/linux/kexec.h typedef u32 note_buf_t[KEXEC_NOTE_BYTES/4]; crashnote is also one part of /proc/vmcore. At first, crashnotes[] address, got by reading sys/devices/system/cpu/cpu0/crash_notes, is stored as one program header, which could be got from “elfcorehdr”. Making crash_notes is done by crash_save_cpu(). crash_kexec->machine_crash_shutdown->crash_save_cpu: 1206 void crash_save_cpu(struct pt_regs *regs, int cpu) 1207 { 1208         struct elf_prstatus prstatus; 1209         u32 *buf; 1210 1211         if ((cpu < 0) || (cpu >= nr_cpu_ids)) 1212                 return; 1213 1214      ...

vmcoreinfo_note contains crash kernel general information, include os version, page size etc.. In kernel, vmcoreinfo_note is stored on vmcoreinfo_note[]. And, vmcoreinfo_note is one part of /proc/vmcore, which is used for debugging with capture kernel brings up. In blog " Understanding Kdump (Loading Part) ", one program header including vmcoreinfo_note's address and length was referenced, and this program header could be got from "elfcorehdr". vmcoreinfo_note[]'s address and length could be got by reading /sys/kernel/vmcoreinfo. When kexec is configured, this function will be triggered with kernel brings up. 1458 static int __init crash_save_vmcoreinfo_init(void) 1459 { 1460         VMCOREINFO_OSRELEASE(init_uts_ns.name.release); 1461         VMCOREINFO_PAGESIZE(PAGE_SIZE); 1462 1463         VMCOREINFO_SYMBOL(init_uts_ns); 1464   ...