Quasi I/O in Modile Devices

移动设备越来越成为消费者最流行的电子产品，在使用消费级的电子产品时，体验永远是用户最看重的一点，手机或者平板电脑的流畅度最能带来直观的感受。目前手机等消费产品中使用的存储空间是越来越大，硬件配置像CPU主频和核数也越来越高，但是存储的性能与响应的时间延时一直都是在逐渐优化过程。

这篇文章中主要集中文件系统的几个常用的接口操作：create()，write()，truncate()，fsync()等。作者通过观察发现，在Android系统中比较大的负载情况下，这些文件系统的操作是对应用的IO响应影响是比较大，特别是前台应用在运行过程中，后台存在大量的异步（asynchronous）IO，而且作者发现其实就是前台的应用在某一个时刻等待异步IO的完成，这与之前认识的异步IO特点就是不需要等待互相矛盾。

文章引入了一种新的IO操作类型，Quasi-Asynchronous I/O（QA-SIO），主要特点是本身以异步下发的IO操作，但是应该被当做同步IO处理，原因是有其他的任务在等待其完成。异步IO提升为QASIO是在运行时完成。

首先作者提出了三种用户应用场景在大量异步IO的情况下减少响应的时间。

1. Launching CONTACTS APP
   当后台4GB的文件正在进行拷贝的时候，进行打开某些CONTACTS应用，整个打开时间增加了140%

2. Burst Mode in the CAMERA APP
   连拍情况下，如果前一次连拍结束，每次拍摄的照片大小设置8MB，后面继续连拍就会出现两次之间的延迟，整体性能大概下降了19%

3. Installing the ANGRY BIRDS APP
   当后台4GB的文件正在的拷贝的时候，安装整个应用平均时间增加了35%

作者发现上述问题有一个共同的地方是，存在一系列的文件系统的操作被一些异步的IO阻塞，导致前台的任务等待后台的异步IO的完成，从而导致比较大的延迟。

然后看下QASIO所产生的几类：

1. 当更改元数据页的时候；这种类型主要是这样：当一个任务调用文件系统操作更改元数据页时，目标元数据可能被它自己或者其他任务dirty，可能已经被kworker作为异步IO下发。
2. 当要更改数据页时；当一个任务要去在数据页中进行追加等，如果这时目标页已经被kworker以异步IO下刷，这时就需要进行等待。
3. 当保证数据要被writeback时；如果一个进程调用fsync()或者truncate(), 当要指向fsync的时候，所有在pagecache中的buffer数据都需要同步下刷，但是如果fsync调用时，已经有部分的dirty page异步下刷，这时就会出现fsync要等待所有的数据页都变成最新才返回，就会有等待异步IO完成的情况。
4. 当要完成discard命令时；当前的系统中，jbd2内核线程是异步发送discard命令，其他的journal则是同步方式；因此，它的执行将会在每次journal提交的时候被阻塞，一直到所有的discard命令都执行完毕。

有时，我们可以看到任务的执行另外一个任务被QASIOs阻塞，这种是一种间接型的阻塞，JBD2以下两种方式就是这样：

1. 当不能获取到journal句柄，在Ext4文件系统中，任务在修改元数据页或者数据页时首先要获取journal句柄。前面已经提到，如果目标页已经异步写入，这时就会出现阻塞。随后包含journal句柄的事务需要提交，但是这个事务会进入locked状态，因为阻塞的任务正持有journal句柄，这时候另外要进行文件操作的任务因为获取不到新的journal句柄而被阻塞。
2. 由于discard不能完成fsync()；fsync系统调用正常情况下需要等待journal提交完成，保证对应文件的元数据持久化，然而，journal提交的处理时间可能因为jbd2内核线程异步发送discard命令而被加长。

然后在看下出现问题的场景如何对应上述的应用场景：

1. 场景A：启动CONTACTS APP
   当一个app的UI要在Android上进行显示的时候需要文件操作更新到数据库SQLite中，启动CONTACTS需要一系列系统调用，如：rename()，write()，fsync(), unlink(). 这些系统调用需要更新元数据，因此他们在遇到大量异步IO的情况下会产生元数据类型的QASIOs
   另外就是UI任务在每次journal提交时可能因为jbd2内核线程执行discard命令产生delay。
2. 场景B：连拍模式
   连拍模式下，因为thumbnail maker任务重复写入1KB的小数据，可能造成目标数据页已经writeback而产生延迟。
   另外，thumbnail maker任务在每次写入数据页的时候都需要获取journal句柄，如果由于上面的原因sleep，经过一定周期时间jbd2提交就会进入locked状态，这时CAMERA想要获取journal句柄进行文件修改就会被阻塞。
3. 场景C：安装ANGRY BIRD APP
   安装APP需要将大量数据写入到底层设备中，并会调用fsync及时下刷，但是如果在后台有大文件的拷贝，page cache就会充满dirty page，这时如果准备被fsync刷入的页前面经过kworker异步发送，就会导致同步情况的QASIOs