5分钟搞懂Linux中直接I/O原理

新闻 Linux
直接IO方式确实能够减少CPU的使用率以及内存带宽的占用,但是有时候也会造成性能的影响。

在介绍直接 I/O 之前,先来介绍下直接I/O这种机制产生的原因。毕竟已经有了缓存I/O(Buffered I/O),那肯定能够像到缓存I/O有缺陷吧,就按照这个思路来。

[[268000]]

什么是缓存 I/O (Buffered I/O)

缓存 I/O 又被称作标准 I/O,大多数文件系统的默认 I/O 操作都是缓存 I/O。在 Linux 的缓存 I/O 机制中,操作系统会将 I/O 的数据缓存在文件系统的页缓存( page cache )中,也就是说,数据会先被拷贝到操作系统内核的缓冲区中,然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间写的过程就是数据流反方向。缓存 I/O 有以下这些优点:

  1. 缓存 I/O 使用了操作系统内核缓冲区,在一定程度上分离了应用程序空间和实际的物理设备。
  2. 缓存 I/O 可以减少读盘的次数,从而提高性能。

对于读操作:当应用程序要去读取某块数据的时候,如果这块数据已经在页缓存中,那就返回之。而不需要经过硬盘的读取操作了。如果这块数据不在页缓存中,就需要从硬盘中读取数据到页缓存。

对于写操作:应用程序会将数据先写到页缓存中,数据是否会被立即写到磁盘,这取决于所采用的写操作机制:

  • 同步机制,数据会立即被写到磁盘中,直到数据写完,写接口才返回;
  • 延迟机制:写接口立即返回,操作系统会定期地将页缓存中的数据刷到硬盘。所以这个机制会存在丢失数据的风险。想象下写接口返回的时候,页缓存的数据还没刷到硬盘,正好断电。对于应用程序来说,认为数据已经在硬盘中。

5分钟搞懂Linux中直接I/O原理

缓存I/O的写操作

缓存 I/O 的缺点

在缓存I/O的机制中,以写操作为例,数据先从用户态拷贝到内核态中的页缓存中,然后又会从页缓存中写到磁盘中,这些拷贝操作带来的CPU以及内存的开销是非常大的。

对于某些特殊的应用程序来说,能够绕开内核缓冲区能够获取更好的性能,这就是直接I/O出现的意义。

5分钟搞懂Linux中直接I/O原理

直接I/O写操作

直接I/O 介绍

凡是通过直接I/O方式进行数据传输,数据直接从用户态地址空间写入到磁盘中,直接跳过内核缓冲区。对于一些应用程序,例如:数据库。他们更倾向于自己的缓存机制,这样可以提供更好的缓冲机制提高数据库的读写性能。直接I/O写操作如上图所示。

直接I/O 设计与实现

要在块设备中执行直接 I/O,进程必须在打开文件的时候设置对文件的访问模式为 O_DIRECT,这样就等于告诉操作系统进程在接下来使用 read() 或者 write() 系统调用去读写文件的时候使用的是直接 I/O 方式,所传输的数据均不经过操作系统内核缓存空间。使用直接 I/O 读写数据必须要注意缓冲区对齐( buffer alignment )以及缓冲区的大小的问题,即对应 read() 以及 write() 系统调用的第二个和第三个参数。这里边说的对齐指的是文件系统块大小的对齐,缓冲区的大小也必须是该块大小的整数倍。

下面主要介绍三个函数:open(),read() 以及 write()。Linux 中访问文件具有多样性,所以这三个函数对于处理不同的文件访问方式定义了不同的处理方法,本文主要介绍其与直接 I/O 方式相关的函数与功能.首先,先来看 open() 系统调用,其函数原型如下所示:

  1. int open(const char *pathname, int oflag, … /*, mode_t mode * / ) ; 

当应用程序需要直接访问文件而不经过操作系统页高速缓冲存储器的时候,它打开文件的时候需要指定 O_DIRECT 标识符。

操作系统内核中处理 open() 系统调用的内核函数是 sys_open(),sys_open() 会调用 do_sys_open() 去处理主要的打开操作。它主要做了三件事情:

  1. 调用 getname() 从进程地址空间中读取文件的路径名;
  2. do_sys_open() 调用 get_unused_fd() 从进程的文件表中找到一个空闲的文件表指针,相应的新文件描述符就存放在本地变量 fd 中;
  3. 函数 do_filp_open() 会根据传入的参数去执行相应的打开操作。

下面列出了操作系统内核中处理 open() 系统调用的一个主要函数关系图。

  1. sys_open()  
  2.  |-----do_sys_open()  
  3.  |---------getname()  
  4.  |---------get_unused_fd()  
  5.  |---------do_filp_open()  
  6.  |--------nameidata_to_filp()  
  7.  |----------__dentry_open() 

函数 do_flip_open() 在执行的过程中会调用函数 nameidata_to_filp(),而 nameidata_to_filp() 最终会调用 __dentry_open() 函数,若进程指定了 O_DIRECT 标识符,则该函数会检查直接 I./O 操作是否可以作用于该文件。下面列出了 __dentry_open() 函数中与直接 I/O 操作相关的代码。

  1. if (f->f_flags & O_DIRECT) {  
  2.  if (!f->f_mapping->a_ops ||  
  3.  ((!f->f_mapping->a_ops->direct_IO) &&  
  4.  (!f->f_mapping->a_ops->get_xip_page))) {  
  5.  fput(f);  
  6.  f = ERR_PTR(-EINVAL);  
  7.  }  

当文件打开时指定了 O_DIRECT 标识符,那么操作系统就会知道接下来对文件的读或者写操作都是要使用直接 I/O 方式的。

下边我们来看一下当进程通过 read() 系统调用读取一个已经设置了 O_DIRECT 标识符的文件的时候,系统都做了哪些处理。 函数 read() 的原型如下所示:

  1. ssize_t read(int feledes, void *buff, size_t nbytes) ; 

操作系统中处理 read() 函数的入口函数是 sys_read(),其主要的调用函数关系图如下:

  1. sys_read()  
  2.  |-----vfs_read()  
  3.  |----generic_file_read()  
  4.  |----generic_file_aio_read()  
  5.  |--------- generic_file_direct_IO() 
  6. ​ 

函数 sys_read() 从进程中获取文件描述符以及文件当前的操作位置后会调用 vfs_read() 函数去执行具体的操作过程,而 vfs_read() 函数最终是调用了 file 结构中的相关操作去完成文件的读操作,即调用了 generic_file_read() 函数,其代码如下所示:

  1. ssize_t  
  2. generic_file_read(struct file *filp,  
  3. char __user *buf, size_t count, loff_t *ppos)  
  4. {  
  5.  struct iovec local_iov = { .iov_base = buf, .iov_len = count };  
  6.  struct kiocb kiocb;  
  7.  ssize_t ret;  
  8.   
  9.  init_sync_kiocb(&kiocb, filp);  
  10.  ret = __generic_file_aio_read(&kiocb, &local_iov, 1, ppos);  
  11.  if (-EIOCBQUEUED == ret)  
  12.  ret = wait_on_sync_kiocb(&kiocb);  
  13.  return ret;  

函数 generic_file_read() 初始化了 iovec 以及 kiocb 描述符。描述符 iovec 主要是用于存放两个内容:用来接收所读取数据的用户地址空间缓冲区的地址和缓冲区的大小;描述符 kiocb 用来跟踪 I/O 操作的完成状态。之后,函数 generic_file_read() 凋用函数 __generic_file_aio_read()。该函数检查 iovec 中描述的用户地址空间缓冲区是否可用,接着检查访问模式,若访问模式描述符设置了 O_DIRECT,则执行与直接 I/O 相关的代码。函数 __generic_file_aio_read() 中与直接 I/O 有关的代码如下所示:

  1. if (filp->f_flags & O_DIRECT) {  
  2.  loff_t pos = *ppos, size;  
  3.  struct address_space *mapping;  
  4.  struct inode *inode;  
  5.   
  6.  mapping = filp->f_mapping;  
  7.  inode = mapping->host;  
  8.  retval = 0;  
  9.  if (!count)  
  10.  goto out;  
  11.  size = i_size_read(inode);  
  12.  if (pos < size) {  
  13.  retval = generic_file_direct_IO(READ, iocb,  
  14.  iov, pos, nr_segs);  
  15.  if (retval > 0 && !is_sync_kiocb(iocb))  
  16.  retval = -EIOCBQUEUED;  
  17.  if (retval > 0)  
  18.  *ppos = pos + retval;  
  19.  }  
  20.  file_accessed(filp);  
  21.  goto out;  

上边的代码段主要是检查了文件指针的值,文件的大小以及所请求读取的字节数目等,之后,该函数调用 generic_file_direct_io(),并将操作类型 READ,描述符 iocb,描述符 iovec,当前文件指针的值以及在描述符 io_vec 中指定的用户地址空间缓冲区的个数等值作为参数传给它。当 generic_file_direct_io() 函数执行完成,函数 __generic_file_aio_read()会继续执行去完成后续操作:更新文件指针,设置访问文件 i 节点的时间戳;这些操作全部执行完成以后,函数返回。 函数 generic_file_direct_IO() 会用到五个参数,各参数的含义如下所示:

  1. rw:操作类型,可以是 READ 或者 WRITE
  2. iocb:指针,指向 kiocb 描述符 
  3. iov:指针,指向 iovec 描述符数组
  4. offset:file 结构偏移量
  5. nr_segs:iov 数组中 iovec 的个数

函数 generic_file_direct_IO() 代码如下所示:

  1. static ssize_t  
  2. generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,  
  3.  loff_t offset, unsigned long nr_segs)  
  4. {  
  5.  struct file *file = iocb->ki_filp;  
  6.  struct address_space *mapping = file->f_mapping;  
  7.  ssize_t retval;  
  8.  size_t write_len = 0;  
  9.   
  10.  if (rw == WRITE) {  
  11.  write_len = iov_length(iov, nr_segs);  
  12.  if (mapping_mapped(mapping))  
  13.  unmap_mapping_range(mapping, offset, write_len, 0);  
  14.  }  
  15.   
  16.  retval = filemap_write_and_wait(mapping);  
  17.  if (retval == 0) {  
  18.  retval = mapping->a_ops->direct_IO(rw, iocb, iov,  
  19.  offset, nr_segs);  
  20.  if (rw == WRITE && mapping->nrpages) {  
  21.  pgoff_t end = (offset + write_len - 1)  
  22.  >> PAGE_CACHE_SHIFT;  
  23.  int err = invalidate_inode_pages2_range(mapping,  
  24.  offset >> PAGE_CACHE_SHIFT, end);  
  25.  if (err)  
  26.  retval = err;  
  27.  }  
  28.  }  
  29.  return retval;  

函数 generic_file_direct_IO() 对 WRITE 操作类型进行了一些特殊处理。除此之外,它主要是调用了 direct_IO 方法去执行直接 I/O 的读或者写操作。在进行直接 I/O 读操作之前,先将页缓存中的相关脏数据刷回到磁盘上去,这样做可以确保从磁盘上读到的是***的数据。这里的 direct_IO 方法最终会对应到 __blockdev_direct_IO() 函数上去。__blockdev_direct_IO() 函数的代码如下所示:

  1. ssize_t  
  2. __blockdev_direct_IO(int rw, struct kiocb *iocb, struct inode *inode,  
  3.  struct block_device *bdev, const struct iovec *iov, loff_t offset,  
  4.  unsigned long nr_segs, get_block_t get_block, dio_iodone_t end_io,  
  5.  int dio_lock_type)  
  6. {  
  7.  int seg;  
  8.  size_t size;  
  9.  unsigned long addr;  
  10.  unsigned blkbits = inode->i_blkbits;  
  11.  unsigned bdev_blkbits = 0;  
  12.  unsigned blocksize_mask = (1 << blkbits) - 1;  
  13.  ssize_t retval = -EINVAL;  
  14.  loff_t end = offset;  
  15.  struct dio *dio;  
  16.  int release_i_mutex = 0;  
  17.  int acquire_i_mutex = 0;  
  18.   
  19.  if (rw & WRITE)  
  20.  rw = WRITE_SYNC;  
  21.   
  22.  if (bdev)  
  23.  bdev_blkbits = blksize_bits(bdev_hardsect_size(bdev));  
  24.   
  25.  if (offset & blocksize_mask) {  
  26.  if (bdev)  
  27.  blkbits = bdev_blkbits;  
  28.  blocksize_mask = (1 << blkbits) - 1;  
  29.  if (offset & blocksize_mask)  
  30.  goto out;  
  31.  }  
  32.   
  33.  for (seg = 0; seg < nr_segs; seg++) {  
  34.  addr = (unsigned long)iov[seg].iov_base;  
  35.  size = iov[seg].iov_len;  
  36.  end += size;  
  37.  if ((addr & blocksize_mask) || (size & blocksize_mask)) {  
  38.  if (bdev)  
  39.  blkbits = bdev_blkbits;  
  40.  blocksize_mask = (1 << blkbits) - 1;  
  41.  if ((addr & blocksize_mask) || (size & blocksize_mask))  
  42.  goto out;  
  43.  }  
  44.  }  
  45.   
  46.  dio = kmalloc(sizeof(*dio), GFP_KERNEL);  
  47.  retval = -ENOMEM;  
  48.  if (!dio)  
  49.  goto out;  
  50.  dio->lock_type = dio_lock_type;  
  51.  if (dio_lock_type != DIO_NO_LOCKING) {  
  52.  if (rw == READ && end > offset) {  
  53.  struct address_space *mapping;  
  54.   
  55.  mapping = iocb->ki_filp->f_mapping;  
  56.  if (dio_lock_type != DIO_OWN_LOCKING) {  
  57.  mutex_lock(&inode->i_mutex);  
  58.  release_i_mutex = 1;  
  59.  }  
  60.   
  61.  retval = filemap_write_and_wait_range(mapping, offset,  
  62.  end - 1);  
  63.  if (retval) {  
  64.  kfree(dio);  
  65.  goto out;  
  66.  }  
  67.   
  68.  if (dio_lock_type == DIO_OWN_LOCKING) {  
  69.  mutex_unlock(&inode->i_mutex);  
  70.  acquire_i_mutex = 1;  
  71.  }  
  72.  }  
  73.   
  74.  if (dio_lock_type == DIO_LOCKING)  
  75.  down_read_non_owner(&inode->i_alloc_sem);  
  76.  }  
  77.   
  78.  dio->is_async = !is_sync_kiocb(iocb) && !((rw & WRITE) &&  
  79.  (end > i_size_read(inode)));  
  80.   
  81.  retval = direct_io_worker(rw, iocb, inode, iov, offset,  
  82.  nr_segs, blkbits, get_block, end_io, dio);  
  83.   
  84.  if (rw == READ && dio_lock_type == DIO_LOCKING)  
  85.  release_i_mutex = 0;  
  86.   
  87. out:  
  88.  if (release_i_mutex)  
  89.  mutex_unlock(&inode->i_mutex);  
  90.  else if (acquire_i_mutex)  
  91.  mutex_lock(&inode->i_mutex);  
  92.  return retval;  

该函数将要读或者要写的数据进行拆分,并检查缓冲区对齐的情况。本文在前边介绍 open() 函数的时候指出,使用直接 I/O 读写数据的时候必须要注意缓冲区对齐的问题,从上边的代码可以看出,缓冲区对齐的检查是在 __blockdev_direct_IO() 函数里边进行的。用户地址空间的缓冲区可以通过 iov 数组中的 iovec 描述符确定。直接 I/O 的读操作或者写操作都是同步进行的,也就是说,函数 __blockdev_direct_IO() 会一直等到所有的 I/O 操作都结束才会返回,因此,一旦应用程序 read() 系统调用返回,应用程序就可以访问用户地址空间中含有相应数据的缓冲区。但是,这种方法在应用程序读操作完成之前不能关闭应用程序,这将会导致关闭应用程序缓慢。

直接I/O 优点

***的优点就是减少操作系统缓冲区和用户地址空间的拷贝次数。降低了CPU的开销,和内存带宽。对于某些应用程序来说简直是福音,将会大大提高性能。

直接I/O 缺点

直接IO并不总能让人如意。直接IO的开销也很大,应用程序没有控制好读写,将会导致磁盘读写的效率低下。磁盘的读写是通过磁头的切换到不同的磁道上读取和写入数据,如果需要写入数据在磁盘位置相隔比较远,就会导致寻道的时间大大增加,写入读取的效率大大降低。

总结

直接IO方式确实能够减少CPU的使用率以及内存带宽的占用,但是有时候也会造成性能的影响。所以在使用直接IO之前一定要清楚它的原理,只有在各项都清晰的情况下,才考虑使用。本人只是介绍了原理,如想深入,建议参考内核相关文档。

责任编辑:张燕妮 来源: 底层软件架构
相关推荐

2017-05-18 11:11:20

Google谷歌开发者大会

2024-01-12 07:38:38

AQS原理JUC

2020-03-03 15:40:51

开发技能代码

2011-01-14 09:25:28

LinuxIO机制

2019-08-09 10:33:36

开发技能代码

2021-06-18 07:34:12

Kafka中间件微服务

2017-03-30 19:28:26

HBase分布式数据

2021-01-27 18:15:01

Docker底层宿主机

2018-09-27 13:56:14

内网外网通信

2021-05-28 07:38:20

内存溢出场景

2009-10-10 15:50:25

2012-06-28 10:26:51

Silverlight

2023-09-18 15:49:40

Ingress云原生Kubernetes

2024-01-16 07:46:14

FutureTask接口用法

2023-12-06 08:48:36

Kubernetes组件

2021-12-01 06:50:50

Docker底层原理

2024-07-05 09:31:37

2024-04-29 07:57:46

分布式流控算法

2019-09-16 09:14:51

2023-12-04 18:13:03

GPU编程
点赞
收藏

51CTO技术栈公众号