Chinaunix首页 | 论坛 | 博客
  • 博客访问: 109769
  • 博文数量: 76
  • 博客积分: 106
  • 博客等级: 民兵
  • 技术积分: 170
  • 用 户 组: 普通用户
  • 注册时间: 2010-11-04 16:55
文章分类

全部博文(76)

文章存档

2014年(47)

2013年(2)

2012年(20)

2011年(7)

分类: LINUX

2014-03-12 13:28:04

原文地址:direct-io 作者:zonian

这两天抽时间把以前的一个遗留的direct-io问题跟踪了下。

       Direct-io的目的在于绕过fscache,直接对block设备上的文件进行读写,其目的在于提高读写性能(以读为例,毕竟少了一次从fs cache 到用户态buffer的拷贝过程),这在文件仅读/写一次的情况下应该是比较比默认的读/写方式效率高(理论上)。

       首先,direct-io是以block设备的block块大小为单位进行读写,因此,用户态分配的bufferlength至少要为block块的整数倍。之所以为一个遗留问题,是因为用户态的所使用的buffer是由一块自己管理的IO内存来分的(以页为分配的基本单位,而vaddr则是由mmap默认去选择的,这里mmap会去调用find_vma从而随机的得到一个vaddr),由于脑袋中想的一直是物理页是以页为单位分配的,页就当然是block块的整数倍,因此在地址上没有多加考虑。问题就出在这里,direct-io要的虚拟内存连续,与你paddr没关系!-_-!(当然有关系,普通的内存管理中,虚拟地址到物理地址的转换是通过查询页表来实现的,页表记录着 paddr >> PAGE_SHIFT, 即页帧号,虚拟地址的在虚拟页帧内的偏移与物理地址页偏移是相同的,在IOMEM用mmap来实物理地址到虚拟地址的转换,而这个地址我们又是让kernel来选择,当然就无法保证页对其,所以fs就认为其物理地址也是非页对其,从而出现了这个现象)因此当初在使用iomem的时候就一直出 INVALID的错误,确还怀疑iomem的页表管理与普通mem页表管理不同(实际没差别)?这里贴出kernel中对vaddr检查的代码:

 

  1. if (offset & blocksize_mask) {
  2.         if (bdev)
  3.              blkbits = bdev_blkbits;
  4.         blocksize_mask = (1 << blkbits) - 1;
  5.         if (offset & blocksize_mask)
  6.             goto out;
  7.     }
  8.     for (seg = 0; seg < nr_segs; seg++) {
  9.         addr = (unsigned long)iov[seg].iov_base;
  10.         size = iov[seg].iov_len;
  11.         end += size;
  12.         if ((addr & blocksize_mask) || (size & blocksize_mask)) {
  13.             if (bdev)
  14.                  blkbits = bdev_blkbits;
  15.             blocksize_mask = (1 << blkbits) - 1;
  16.             if ((addr & blocksize_mask) || (size & blocksize_mask))
  17.                 goto out;
  18.         }
  19.     }
  20. //注:iov:管理用户态buffer, offset为读写的起始地址(当然也该block块大小对齐)

问题找到了,接下来就应该测试下这个direct-io到底有多好的性能(在x86下用系统内存进行测试)

测试代码如下:

 

  1. #define TESTFILE "test"
  2. #define BUFFSIZE (4096)

  3. int
  4. main(void)
  5. {
  6.     int fd, ret, i;
  7.     void *buff, *align;
  8.     
  9.     buff = valloc(BUFFSIZE);
  10.     if ( !buff ) {
  11.         perror("alloc failed");
  12.         return -1;
  13.     }

  14.     fd = open(TESTFILE, O_RDONLY | O_DIRECT, 0666); //在这里区别是否用direct-io
  15.     if ( fd <= 0 ) {
  16.         perror("open file directly failed");
  17.         return -1;
  18.     }
  19.     
  20.     for ( i = 0; i < 10240; i++) {
  21.         ret = read( fd, buff, BUFFSIZE);
  22.         if ( ret < 0 ) {
  23.             perror("read failed");
  24.         }
  25.     }

  26.     free(buff);
  27.     return 0;
  28. }

这里循环读写 4k*10240 = 40M的数据,可测试结果确出乎人意外。这里做了direct non-direct的测试,在测试前均刷了系统的页高速缓存和目录项缓存(echo 3 > /proc/sys/vm/drop_caches ),这样,读test文件都应该从block设备读,应该满足测试要求。

direct-io测试结果:

real  0m1.216s

user 0m0.008s

sys  0m0.568s

non-direct-io测试结果:

real  0m0.639s

user 0m0.000s

sys  0m0.048s

这样不管是指令的执行时间还是在内核态的是时间,非direct-io都要少于direct-io,世界怎么反过来了?Why?接下去要好好查查原因

原因: 在进行DirectIO读写时,fs会根据用户态请求 iovec,将请求封为一个bio,将这个bio交给block层去填数据。由于bio是根据iovec来的,因此,fs就不可能实现文件的预读,而非directIO系统会根据当前的操作调整文件的预读窗口,将后续内容读到页高速缓存,这样后续的读操作就完全是mem copy了,速度当然是directIO不可比的。我们可以在非directIO时关掉系统预读来测测其性能。代码如下:

 

  1. #define TESTFILE "test"
  2. #define BUFFSIZE (4096)

  3. int
  4. main(void)
  5. {
  6.     int fd;
  7.     int ret;
  8.     void *buff, *align;
  9.     int i = 0;
  10.     
  11.     buff = valloc(BUFFSIZE);
  12.     if ( !buff ) {
  13.         perror("alloc failed");
  14.         return -1;
  15.     }

  16.     fd = open(TESTFILE, O_RDONLY , 0666);
  17.     if ( fd <= 0 ) {
  18.         perror("open file directly failed");
  19.         return -1;
  20.     }

  21. #if 1
  22.     ret = posix_fadvise(fd, 0, 0, POSIX_FADV_RANDOM); //这里将文件的访问方式改为随机读,这样系统就会关闭其
  23.     if ( ret ) {                                      //预读窗口
  24.         printf("disable readahead disabled failed\n");
  25.     }
  26. #endif
  27.     
  28.     for ( i = 0; i < 10240; i++ ) {
  29.         ret = read( fd, buff, BUFFSIZE);
  30.         if ( ret < 0 ) {
  31.             perror("read failed");
  32.         }
  33.     }

  34.     free(buff);
  35.     return 0;
  36. }

测试结果如下:

real 0m1.259s
user 0m0.000s
sys 0m0.608s

这样是不是就是我们想看到的结果了,无论是real、sys directIO都少于non-directIO。

     看来direct-IO并不是我们想象中的利器,并不能有效的提高我们的性能。但既然存在,应该有它存在的意义吧。从实验可以猜出一二:首先,数据访问方式为随机访问,但只访问一次(怎么可能呢, 开玩笑了)。使用directIO就意味着不会消耗系统的缓冲,也就是说减轻了内存回收的压力,因此,它可能存在的意义在于,存在自己管理文件cache的情况(例如数据库)。

      Ok,后面有时间会给出directIO的具体流程。

 

 

阅读(434) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~