uboot将控制权交给 kernel，kernel入口为 stext，主要完成验证是否支持此 CPU、验证 uboot 传入的设备树（dtb）合法性、使能 MMU 等工作，最终会调用 C 函数 start_kernel()相当于内核的 main 函数，内核的生命周期就是从执行这个函数的第一条语句开始的，直到最后一个函数 reset_init()，内核将不再从这个函数中返回。本文详解了kernel启

但是当需要申请连续物理内存页框的时候，随着进程的对内存的申请和释放，系统的内存会不断的区域碎片化，分页机制就不一定能保证有足够的连续物理内存页了。当回收一个内存块，会将该内存块插入到对应的链表中，然后查询其buddy内存块是否也在链表上，如果是则合并两个内存块，然后插入到大一级的内存块链表中。如果大一级的内存块链表中没有空闲内存块，则会向更大的内存块链表中查找，然后一层层二分下来，分到合适大小后分

CPU访问外设的数据寄存器和状态寄存器时，也是需要将寄存器的值映射到内存上进行读写，外设寄存器的值由硬件修改，也可以由CPU读写，因此外设和CPU对寄存器映射的内存访问也是异步的。在没有写回之前，核心B的cache中的同个数据还没改，当B去访问它时则会与A不一致。因为DMA是直接内存访问，对内存的访问不需要经过CPU，因此如果DMA修改了内存上的CPU访问过的数据，而CPU的cache中并不知道内

在 32 位操作系统，因为进程最大只能申请 3 GB 大小的虚拟内存，所以直接申请 8G 内存，会申请失败。在 64 位操作系统，因为进程最大可以申请 128 TB 大小的虚拟内存，即使物理内存只有 4GB，申请 8G 内存也是没问题，因为申请的内存是虚拟内存。如果这块虚拟内存被访问了，要看系统有没有 Swap 分区：* 如果没有 Swap 分区，因为物理空间不够，进程会被OOM机制杀掉

32位机中的虚拟内存大小为4GB，其中0\~3GB用于用户空间，3\~4GB用于内核空间。内核的内存空间只有1G，这一部分内存在进程中共享，与用户空间隔离，用户空间不能访问。内核空间在虚拟内存上分为三个区间：从低到高分别是：

分段和分页的工作方式相似，都是非连续存储。分段的逻辑地址=段号+段内偏移。段表存放段描述符。段描述符=段基址+段界限。物理地址=段基址+段内偏移。分页的虚拟地址=页号+页内偏移。页表存放页面映射。页面映射=虚拟页号+物理页号。物理地址=物理页号+页内偏移。

使用malloc时，会从两个区分配内存，分别是 文件映射区 和 堆区。当申请的内存小于 128K 时，会通过 brk() 系统调用，从堆区分配内存。当申请的内存大于 128K 时，会通过 mmap() 系统调用，从文件映射区分配内存。下面讲两种分配方式的区别。

为什么要有虚拟内存？1. 让每个进程都有独立的内存空间，每个进程都有自己的私有页表，提供一个可以执行多进程的环境。2. 利用程序运行局部性原理，允许进程的内存空间超过物理内存大小。3. 页表中维护着页的权限属性，使内存访问更安全。

malloc申请的是虚拟内存，只有在程序去访问时，才会触发缺页异常进入内核态，在缺页中断函数中建立物理内存映射。如果物理内存充足，则直接建立页框与页的映射。当物理内存不足时，内核会进行物理内存回收，内存回收的方式主要有：1. 后台内存回收（kswapd）2. 直接内存回收（direct reclaim）3. OOM机制（Out of Memory）三种内存回收方式按内存的紧缺程度递进。

Ubuntu配置PicGo图床Ubuntu20.04系统搭配gitee和picgo实现自制图床 配置typora 和 picgo-core实现粘贴图片自动上传到图床的功能。注意：后期可能gitee会设置防盗链来限制白piao图床的行为，因此最好在使用图床的同时也在本地备份一份图片，用YAML设置自动上传。如果有条件快速访问github，也可以用github和cdn加速来做图床。1. 软件下载typ