linux readahead预读机制分析(linux 4.14)

原创 Vier 酷派技术团队

一、基本概念

设计背景

文件访问类型一般是顺序的，访问[A, B]范围的数据后，接下来很可能访问[B+1, B+N]数据。由于访问磁盘、flash等存储器件比较耗时，在访问 [A, B]的时候，如果提前把[B+1, B+N]数据从存储器件读取到ram中，那么后继需要用[B+1, B+N]数据时，就不需要通过耗时的disk io从存储器件读取数据了，从而提高性能。

预读带来的好处

对于顺序读，适量的预读可以提升性能。原因如下：

1）提前读取数据，避免耗时的disk io读取数据

预读数据缓存在page cache中（struct file->f_mapping->page_tree），用的时候，直接从缓存读取，不需要从存储器件读取数据（这个操作耗时）。

2）提高存储栈、器件处理效率

预读本质是提前读取即将访问的数据，以备将来使用，这意味着“当前数据”和“预读数据”的逻辑地址是连续的，这两个io请求在内核存储栈中（filesytem-->block layer-->device）就可以进行合并（merge）处理。处理一个io请求，即可满足原先的两个io请求需求。

3）降低硬中断、软中断带来的负载

器件处理io请求完成时，内核通过硬中断、软中断处理io完成时的工作，合并io请求，可降低中断数量，减少中断带来的额外负载。

4）避免存储栈拥塞导致read响应不及时

器件的io数量是有上限的（默认值/sys/block/sdc/queue/nr_requests=128），当器件待处理的io数超过7/8 * nr_requests时，存储栈进入拥塞状态并限制生成io请求的速度；当待处理的io请求数达到最大值nr_requests时，read因申请不到struct request而阻塞等待，直至一些io请求处理完后被存储栈回收，read、write才能转换成io请求，然后提交io请求给器件处理。合并io请求，可减少io数量，降低存储栈拥塞的概率。

5）避免磁盘磁头来回移动

这一点是针对机械硬盘的。文件数据[A，B]和[B+1, B+N]在逻辑地址上是连续的，磁头只需往一个方向移动。作为对比，访问[A，B]，[A-N, A-1]，[B+1, B+N]，就会出现磁头来回移动的情况，磁头的机械运动是很耗时的。

预读带来的坏处

1）对于随机读，预读的数据不会被用到，白白占用了存储器件带宽及系统内存。

2）大量预读可能导致io负载增大。

3）大量预读可能导致内存压力增大。

同步预读 & 异步预读

源码中有两个函数page_cache_sync_readahead和page_cache_async_readahead，分别称作同步预读、异步预读。这个地方容易让人迷糊，需解释一下二者的区别。

同步预读：从存储器件读取多个page数据，一些page给read使用，一些page留给将来使用。在下图，read文件数据时，根据page->index在page cache中（struct file->f_mapping->page_tree）找需要的页面（蓝色页面），如果找不到就执行同步预读page_cache_sync_readahead。同步预读根据待读数据的逻辑地址、待读page数量及地址信息，封装成bio，然后调用submit_bio提交给器件处理。不过要注意预读提交bio后就返回了，并不会等待page中的数据变成PageUptodate。

异步预读：本次读的page纯粹是为将来准备的，触发异步预读的read目前不需要这些数据。这些page提前从存储器件读取并将page加入到page cache中。

二、关键数据结构及原理

数据结构

预读的核心数据结构是struct file_ra_state，定义在linux/fs.h中：

/* * Track a single file's readahead state *//* 这个结构体是struct file相关的，描述了file的预读状态。预读按预读窗口推进，预读窗口中含有file_ra_state->size个page。   read访问预读窗口中的page，访问到第size-async_size个page，也   即预读窗口中还剩async_size个page没有访问时，启动异步预读读入一   批新的page作为预读窗口 */struct file_ra_state {    //从start这个page开始读    pgoff_t start;            /* where readahead started *///读取size个page放入预读窗口。如内存不足无法申请page,则预读小于size个page    unsigned int size;        /* # of readahead pages */    //预读窗口中还剩async_size个page时,启动异步预读    unsigned int async_size;    /* do asynchronous readahead when                       there are only # of pages ahead */    //预读窗口上限值(单位: page).      默认等于struct backing_dev_info->ra_pages, 可通过fadvise调整。如果read需要读的page数量小于ra_pages，最多读取ra_pages个页面.      如果read需要读的page数量大于ra_pages，最多读取 min { read的page数量,存储器件单次io最大page数量 }个页面.      预读窗口中当前有多少个页面由size成员变量表示.    unsigned int ra_pages;        /* Maximum readahead window */    unsigned int mmap_miss;        /* Cache miss stat for mmap accesses */    //最后一次的读位置(单位:字节)    loff_t prev_pos;        /* Cache last read() position */};

关键字段意义如下图：

原理

read请求N 个page数据，通过预读从存储器件读取M个page数据（M ＞ N），并对其中的第a个page设置PageReadahead标记（0 ≤ a < N）。PageReadahead标记起到一个标识作用，表示预读窗口中剩余的page不多了，需要启动异步预读再读入一批page存放page cache。

如果是顺序读，肯定会读到PageReadahead标记的页（单线程读的场景），或者读到预读窗口的最后一个页（多线程穿插读的场景），所以代码作者认为，如果访问到这两种页就是顺序读（注意：这样的判断不是很准，但代码写起来简单高效），否则认为是随机访问。

如果是顺序访问，预读窗口在之前的基础上扩大2倍或者4倍（上限值不超过struct file_ra_state->ra_pages），然后从存储器件读入数据填充这些page，并缓存在page cache中，最后，在新读入的这批page中选定一个page设置PageReadahead标记（一般是新读入的这批page中的第一个page）。

如果是随机访问，预读机制仅从存储器件中读取read函数需要的数据，read请求几个page，就读几个page，并缓存在page cache中。可以看出随机读不会预读多余的page，另外注意随机读不更改预读窗口。

三、预读示例

按4k顺序访问文件的[0, 8*4K]的数据（顺序访问），然后lseek到108*4k处访问文件（随机访问）。过程如下：

1）访问第0个page数据

page->index=0的页面在page cache中找不到，触发同步预读page_cache_sync_readahead，一次性读了4个page（read需要1个page，预读3个page。预读page数量与实际请求的page数量、file_ra_state->ra_pages有关，通过get_init_ra_size计算）。本次预读建立的预读窗口如下：

注意，预读窗口中第ra->size - ra->async_size = 1个page，即page->index=1设置了PageReadahead标记。

2）访问第1个page数据

page->index=1的页面在page cache中能找到（预读命中），不需要从存储器件中读取数据。又因该page有PageReadahead标记，触发异步预读page_cache_async_readahead，预读页面数量由get_next_ra_size计算得到，因为本次请求的数据起始位置与上一次读结束位置相同，属于顺序读，get_next_ra_size加大预读量，预读量从之前的4 page增大到8 page。本次预读建立的预读窗口如下：

注意，预读窗口中第ra->size - ra->async_size = 0个page，即page->index=4设置了PageReadahead标记。

3）访问第2、3个page数据

这两个page在page cache中可以找到（预读命中），直接从page cache中读取数据。

4）访问第4个page数据

page->index=4的页面在page cache中可以找到（预读命中），直接从page cache中读取数据。不过这个page设置了PageReadahead标记，触发异步预读page_cache_async_readahead，由于是顺序读，get_next_ra_size将预读量从8 page增大到16 page，本次预读建立的预读窗口如下：

后继的顺序访问流程重复上面过程，遇到page被标记成PageReadahead，增大预读量（最大不超过struct file_ra_state->ra_pages）后启动异步预读。

5）lseek跳到108*4k处访问第108个page数据

访问page->index=108的page，不符合顺序读的条件，所以代码判断成随机读。如果是随机读，则不做预读，read请求几个页的数据，就从存储器件中读几个页数据（ondemand_readahead --> __do_page_cache_readahead）。

注意，这次随机读，不会更改预读窗口状态。

四、关键代码分析

同步预读generic_file_buffered_read --> page_cache_sync_readahead 与异步预读generic_file_buffered_read --> page_cache_async_readahead都会调用ondemand_readahead，在这个函数中计算预读量，然后ra_submit提交io请求。

/* @offset: 从哪个page开始读    @req_size: 需要读多少个page，这是read需要的数量   如果是顺序读，ondemand_readahead读取至少req_size个page。   如果是随机读，ondemand_readahead仅读取req_szie个page。*/ondemand_readahead(struct address_space *mapping,       struct file_ra_state *ra, struct file *filp,       bool hit_readahead_marker, pgoff_t offset,       unsigned long req_size){  struct backing_dev_info *bdi = inode_to_bdi(mapping->host);  unsigned long max_pages = ra->ra_pages;  unsigned long add_pages;  pgoff_t prev_offset;
  /*   * If the request exceeds the readahead window, allow the read to   * be up to the optimal hardware IO size   *//* read请求的page大于预读窗口大小，预读的page数量上调至存储器件单次io最大的page数量 */  if (req_size > max_pages && bdi->io_pages > max_pages)    max_pages = min(req_size, bdi->io_pages);
  /*   * start of file   */  if (!offset)    goto initial_readahead;
  /*   * It's the expected callback offset, assume sequential access.   * Ramp up sizes, and push forward the readahead window.   *//*  条件1：offset == ra->start + ra->size - ra->async_size
             /         同步建立的预读窗口         \            /                                      \           |----------------------------------------|           |    |   |   | ^ |   |   |   |   |   |   |           |--------------|-------------------------|                          |             ra->start + ra->size - ra->async_size             该page设置了PageReadahead
           上图是同步预读建立的预读窗口，从第0个page到第ra->size - ra->async_size           个page，是read需要用的，后面的page是预留给下次read用的。           读到第ra->size - ra->async_size个pag，表明预读窗口已经开始使用，           需要启动异步预读，读入一批page建立一个新的预读窗口，为下下次read做准备。
    条件2：offset == ra->start + ra->size                             前一次     /      异步建立的预读窗口      \             预读窗口   /                                \           -----------|-----------------------------------|               |  |  | ^ |  |  |  |  |  |  |  |  |  |  |  |             ------------|-----------------------------------|                     |          ra->start + ra->size(前一次预读用完了，执行下一个预读窗口的第一个page)          该page设置了PageReadahead
          异步预读建立的预读窗口中，第一个page标记为PageReadahead，访问到这个标记的          页面，表明新预读窗口已经开始使用，需要启动异步预读，读入一批page建立一个新的          预读窗口，为下下次read做准备。
    满足这两个条件，可认为本次read预上一次read是顺序读类型 (见原理部分描述）。    这个条件是不准确的，但是代码实现简单高效。*/  if ((offset == (ra->start + ra->size - ra->async_size) ||       offset == (ra->start + ra->size))) {    ra->start += ra->size;        /*既然是顺序读，就扩大预读窗口：  如果当前预读窗口大小ra->size < 1/16 * 允许读的最多page数  1）则预读窗口在原基础上扩大4倍。否则扩大2倍。  2）扩大后的窗口大小，不能超过“允许读的最多page数量”*/    ra->size = get_next_ra_size(ra, max_pages);    ra->async_size = ra->size;    goto readit;  }
  /*   * Hit a marked page without valid readahead state.   * E.g. interleaved reads.   * Query the pagecache for async_size, which normally equals to   * readahead size. Ramp it up and use it as the new readahead size.   *//* 多线程顺序读一个文件（interleaved read），破坏了file->ra_state，所以没法根据前面的条件   判断出是顺序读类型。如果是顺序读，最终一定会访问到预读窗口中的PageReadahead标记的page。   所以，反过来推，访问到PageReadahead标记的page，就认为是顺序读。当然这样的判断是不准确的，   但准确率高，代码简单。*/  if (hit_readahead_marker) {    pgoff_t start;
/* offset + 1开始，找到第一个不在page cache中的文件数据页，作为预读的开始 */    rcu_read_lock();    start = page_cache_next_hole(mapping, offset + 1, max_pages);    rcu_read_unlock();
    if (!start || start - offset > max_pages)      return 0;
    ra->start = start;    ra->size = start - offset;  /* old async_size */    ra->size += req_size;    ra->size = get_next_ra_size(ra, max_pages);    ra->async_size = ra->size;    goto readit;  }
  /*   * oversize read   */  if (req_size > max_pages)    goto initial_readahead;
  /*   * sequential cache miss   * trivial case: (offset - prev_offset) == 1   * unaligned reads: (offset - prev_offset) == 0   *//* 上面的场景根据下面3个条件判断是否是顺序读：   offset == ra->start + ra->size - ra->async_size   offset == ra->start + ra->size   hit_readahead_marker   代码执行到这里，属于随机读场景。*/  prev_offset = (unsigned long long)ra->prev_pos >> PAGE_SHIFT;  if (offset - prev_offset <= 1UL)    goto initial_readahead;
  /*   * Query the page cache and look for the traces(cached history pages)   * that a sequential stream would leave behind.   */  if (try_context_readahead(mapping, ra, offset, req_size, max_pages))    goto readit;
  /*   * standalone, small random read   * Read as is, and do not pollute the readahead state.   *//* read请求req_size，__do_page_cache_readahead只读req_size个page。注意2点：   1）__do_page_cache_readahead-->read_pages条件io就返回了，不会等待page变成PageUptodate。   2）__do_page_cache_readahead不会更改 struct file_ra_state。*/  return __do_page_cache_readahead(mapping, filp, offset, req_size, 0);
initial_readahead:/* 第一次读文件，初始化预读窗口 */  ra->start = offset;  ra->size = get_init_ra_size(req_size, max_pages);  ra->async_size = ra->size > req_size ? ra->size - req_size : ra->size;
readit:  /*   * Will this read hit the readahead marker made by itself?   * If so, trigger the readahead marker hit now, and merge   * the resulted next readahead window into the current one.   * Take care of maximum IO pages as above.   *//* hit_readahead_marker预期建立了一个预读窗口A，待访问offset刚好是这个预读窗口的第一个page，   这说明访问A窗口，后面没有预留的预读窗口了，需建立下一个预读窗口B备用，既然A、B都还没预读，   就合并后一起预读。*/  if (offset == ra->start && ra->size == ra->async_size) {    add_pages = get_next_ra_size(ra, max_pages);    if (ra->size + add_pages <= max_pages) {      ra->async_size = add_pages;      ra->size += add_pages;    } else {      ra->size = max_pages;      ra->async_size = max_pages >> 1;    }  }
/* ra_submit --> __do_page_cache_readahead尽量分配ra->size个page，   分配失败就停止分配，这些page加入page_pool链表。
   read-->page_cache_sync_readahead，假设read需要读取nr_to_read个page，   预读M个page，则第nr_to_read个page（从0开始计数）设置PageReadahead标记。
   read-->page_cache_async_readahead，则预读的第0个page（从0开始计数）设置   PageReadahead标记。
   ra_submit -->__do_page_cache_readahead --> read_pages调用   mapping->a_ops->readpages或者mapping->a_ops->readpage依次读入page_pool   链表中的page。
   ra_submit提交io后就返回，不会等待page变成PageUptodate。*/  return ra_submit(ra, mapping, filp);}

五、代码待优化的地方

场景

generic_file_buffered_read -->page_cache_sync_readahead或page_cache_async_readahead --> ondemand_readahead --> ra_submit --> __do_page_cache_readahead 会把刚刚申请的一批page（用于预读）加入到page cache中，如果读失败了，这些page并不会从page cache中清除，只是标记成PageError。

问题

generic_file_buffered_read -->find_get_page到page，但不是PageUptodate状态，则认为io错误导致的问题，就通过mapping->a_ops->readpage重新读取单个page数据。所以预读发生io err后，后继read不会批量读入这些page了，只会单个page读，性能较差。

解决

对于这个问题，5.18内核版本已经修复https://lkml.org/lkml/2022/2/10/14。

继续滑动看下一个