Linux内核File cache机制(中篇)

在之前的公众号文章中,我们介绍过File cache的定义,其读流程及写流程,想了解上篇详情的可阅读:Linux内核File cache机制(上篇)

本篇则接上篇,主要介绍Linux mmap读文件流程涉及缺页中断。

一、mmap及缺页中断读文件流程分析

上面篇幅,“什么是Filecache”篇幅介绍了文件缓存框架,走读了read()流程中涉及文件缓存的操作流程。对于用户来说,读过程一般是同步读的过程(当然也有异步读的接口,其思想跟文件缓存异步预读机制类同,不再阐述),其执行完接口调用后所需数据就已经在内存中了,而操作的时候就通过write()等接口进行读写。

除了以上的接口,文件缓存的读取和使用是否还有其他方法?答案是肯定的,例如mmap()等接口可以实现将文件映射到用户地址空间,进程可以像访问普通内存一样对文件进行访问。mmap接口从内核的归属上是内存接口,Linux系统对于用户内存分配总是苛刻的,当用户分配内存时,内核优先只给虚拟内存(MAP_POPULATE等模式本文不作讨论),只有使用时才分配物理内存,通过mmap接口进行文件映射属于内核内存的管理框架内,自然也符合这个管理思想。

那么系统怎么及时地给用户分配物理内存呢?这里就引出缺页中断的概念:

  • 当用户访问虚拟地址时发现地址没有映射到具体的物理内存空间,则触发中断进入内核态,进行物理内存填充,本文只关注文件页面的缺页中断。

  • 对于文件缓存的缺页中断,另外一种触发的场景也非常常见:文件缓存因为内存紧张被系统回收了,因为回收的过程会进行虚拟内存解映射,此时用户再次访问到之前分配的虚拟地址时,同样也需要进入缺页中断流程进行数据的填充。关于文件缓存的回收,放到“Filecache 回收流程分析”章节,读者有兴趣可以进行查阅。

本篇幅通过分析mmap/munmap调用执行流程和文件缓存的缺页中断流程,了解该路径下文件缓存的读取过程。

1. mmap函数生命周期

mmap系统调用用于将用户空间的一端内存区域映射到内核空间,根据传递参数的不同,其可以实现共享内存、单独分配匿名内存以及映射文件页面等。本文主要阐述映射文件缓存,普通文件被映射到进程地址空间后,进程可以像访问普通内存一样对文件进行访问,而不需要调用read()/write()接口。

  • addr:是否指定映射的内存区域的起始地址,NULL表示由内核指定;

  • length:要映射的内存区域大小;

  • prot:内存保护权限的标志;

  • flags:执行映射对象的类型,例如是否共享、是否锁定映射内存、是否匿名映射(不与文件关联)等;

  • fd:文件描述符,内核通过该句柄来寻找具体的文件,如果要映射文件,必须正确地传递该参数。另外调用返回后,fd可以关闭,但是映射依然有效;

  • offset:表示映射对象(文件)的内容的位置;

对于具体的参数使用可以通过man mmap进行查阅。对于文件映射,其mmap的生命周期如下:

mmap系统调用最终调用到内核的ksys_mmap_pgoff接口,文件映射则通过文件描述符得到file结构体,然后最终调用到do_mmap函数,MAP_POPULATE本文不阐述。

do_mmap执行可以简单归纳如下:

  • get_unmmaped_area:获取虚拟地址;

  • mmap_region

  • vm_area_alloc:为虚拟地址申请vma抽象结构体;

  • 初始化vma结构体,包括其实虚拟地址、vm_flags(权限)、vm_file赋值文件结构体指针等和文件映射相关的成员;

  • call_mmap:调用文件系统的mmap函数集;

get_unmmaped_area用于在进程虚拟地址中找到一块合适的空闲地址,内核中是通过红黑树进行管理和查找,对于虚拟内存的管理框架,如果读者有兴趣,可以查阅文章《进程内存管理初探》。(虚拟内存框架是相对抽象的子系统,包括vma、vm_struct等抽象结构体以及操作函数集合、地址管理逻辑等,如果读者有兴趣,可以在评论区留言出专篇)

下面走读一下mmap_region函数,一探mmap的核心逻辑,函数定义于mm/mmap.c中:

函数的逻辑主干很清晰,就不在细述。最后调用call_mmap函数通过mapping->a_ops->mmap回调文件系统操作函数集,以ext4文件系统为例,定义在fs/ext4/file.c中:

至此mmap函数调用就结束了,可能读者会很疑惑:mmap构建了一个vma结构体后什么都没做?其实非MAP_POPULATE分支的mmap函数就是构建vma结构体,该结构抽象管理一段虚拟地址。如本章节篇头提及,Linux内核对用户内存分配是很苛刻的,从内核的角度:因为物理内存是公共资源且比较紧缺,用户申请分配物理内存可能不用,避免共用资源浪费,所以就只先给虚拟内存,因为虚拟内存是属于进程内部独立的,只影响进程内部,对系统的影响仅仅是增加了vma等管理结构体的内存占用开销。

2. 文件缓存的缺页中断处理流程

用户经过mmap接口后,得到一段虚拟内存,其没有物理载体,即没有承载任何用户需要的数据,那么当用户访问该虚拟内存后,怎么获取数据?答案就是Linux 的缺页中断机制,简单概括:

  • 用户访问虚拟地址,MMU发现虚拟地址没有映射到物理内存;

  • 触发中断进行缺页处理流程;

  • 根据vma结构体成员判断是哪种缺页的类型,进行物理页面分配以及数据填充;

Linux根据内存用途分成多种页面,缺页中断也根据页面类型会走不同的分支。本文只讨论文件缺页中断,其他类型可根据相同思路走读代码。以arm处理器,其处理流程如下:

其核心处理阶段包括:

  • 平台的缺页中断;

  • 内存核心框架,衔接到文件系统的fault回调函数;

  • 文件缓存管理框架进行文件页面预读;

  • 通用块设备层、IO调度层和设备驱动层进行数据读取;

本文走读前三部分,最后一部分放在IO和文件系统篇幅,后续更新。

(1)缺页中断

缺页中断跟正常的中断处理流程相似,硬件触发经过汇编代码后跳转到do_DataAbort函数处理,定义在arch/arm/mm/fault.c,arm平台有两个寄存器用于记录中断的信息:

  • FSR:失效状态寄存器

  • FAR:失效地址寄存器

内核使用fsr_info结构体抽象异常处理操作集合:

以二级页表架构为例子,定义于arch/arm/mm/fsr-2level.h中:

通过do_page_fault()调用到__do_page_fault函数:通过当前进程的mm_struct和异常的地址得到vma结构体,然后调用handle_mm_fault函数。

handle_mm_fault函数定义在mm/memory.c中,此时已经进入内存管理框架内,该函数主要分配页表,然后通过handle_pte_fault函数,针对不同的页面类型,进行分支处理:

处理流程也很清晰,根据不同的情况走不同的分支,do_fault函数用于处理文件页面的缺页中断,当然文件页面的缺页中断也有不同的原因:

本文走读do_read_fault流程,其他分支读者可以自行分析,其逻辑大同小异。

__do_fault函数通过 vma->vm_ops->fault()回调到具体文件系统的操作函数集合,前文已知vm_ops函数操作集是在具体的文件系统赋值的,以ext4文件系统为例,ext4_filemap_fault通过filemap_fault函数进行文件页面读取。

(2)filemap_fault

filemap_fault是文件缺页中断的核心处理函数,定义于mm/memory.c中,其逻辑作用:

  • 判断页面是否在文件缓存中,如存在则判断是否需要异步预读;

  • 如不存在则进行同步预读;

其主要的逻辑还是集中在预读窗口的构建。

函数主干简化后如上,逻辑很清晰就不再细述。关注一下此时的同步预读和异步预读策略跟read分析的预读流程,是否存在不同。

  • do_async_mmap_readahead函数

首先是异步预读do_async_mmap_readahead函数:

@1中PG_Readahead标志,表示该页面上次是提前异步读取的第一个页面,在“read发起读文件流程分析:4.1章节”的__do_page_cache_readahead中有分析。当前如果访问到这个文件表示,上次提前预读的页面被命中,那么可能是顺序读,此时需继续进行异步预读,page_cache_async_readahead已经在“read发起读文件流程分析”章节分析,这里不再累述。

  • do_sync_mmap_readahead函数

ra_submit通过__do_page_cache_readahead函数进行预读,该函数在“read发起读文件流程分析”章节都已经分析。

3. munmap函数生命周期

munmap系统调用逻辑非常简单:

  • 内核根据虚拟地址找到vma结构体;

  • unmap_region进行解映射,并释放页表

  • remove_vma_list将vma从用户进程的mm_struct中剥离

这里需要注意的是,调用munmap接口后,是否文件缓存就会一定马上被回收?答案是否定的:

  • 首先文件页面可能被其他进程映射使用;

  • 其次Linux系统对待文件缓存还是比较“博爱”的,除非用户主动调用drop_cache等接口将文件缓存从内存刷出,不然内核会尽量将文件缓存保存在内存中,避免下次用户使用时需要再次从磁盘中读取。既然是“尽量”,那就得有限度,该限度就是内核空闲内存是否低于LOW_WATERMARK水位线?如果低于该值,就会进行内存回收,其中就包括文件缓存的回收。

二、File cache回收流程分析

Linux File cache的回收涉及的知识点很多,包括内存管理LRU机制、workingset机制、内存回收shrink机制和脏页管理机制等,此部分内容放置在《Linux内核File cache机制(下篇)》中,后续发布,有兴趣的可以关注。

长按关注

内核工匠微信

Linux 内核黑科技 | 技术文章 | 精选教程

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

OPPO内核工匠

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值