linux異步IO的兩種方式【轉】
轉自：https://blog.csdn.net/shixin_0125/article/details/78898146
知道異步IO已經很久了，但是直到最近，才真正用它來解決一下實際問題（在一個CPU密集型的應用中，有一些需要處理的數據可能放在磁盤上。預先知道這些數據的位置，所以預先發起異步IO讀請求。等到真正需要用到這些數據的時候，再等待異步IO完成。使用了異步IO，在發起IO請求到實際使用數據這段時間內，程序還可以繼續做其他事情）。
假此機會，也順便研究了一下linux下的異步IO的實現。
linux下主要有兩套異步IO，一套是由glibc實現的（以下稱之為glibc版本）、一套是由linux內核實現，並由libaio來封裝調用接口（以下稱之為linux版本）。
glibc版本
接口
glibc版本主要包含如下接口：
int aio_read(struct aiocb *aiocbp); /* 提交一個異步讀 */
int aio_write(struct aiocb *aiocbp); /* 提交一個異步寫 */
int aio_cancel(int fildes, struct aiocb *aiocbp); /* 取消一個異步請求（或基於一個fd的所有異步請求，aiocbp==NULL） */
int aio_error(const struct aiocb *aiocbp); /* 查看一個異步請求的狀態（進行中EINPROGRESS？還是已經結束或出錯？） */
int aio_suspend(const struct aiocb * const list[], int nent, const struct timespec *timeout); /* 阻塞等待請求完成 */
其中，struct aiocb主要包含以下字段：
int aio_fildes; /* 要被讀寫的fd */
void * aio_buf; /* 讀寫操作對應的內存buffer */
size_t aio_nbytes; /* 需要讀寫的字節長度 */
int aio_reqprio; /* 請求的優先級 */
struct sigevent aio_sigevent; /* 異步事件，定義異步操作完成時的通知信號或回調函數 */
實現
glibc的aio實現是比較通俗易懂的：
1、異步請求被提交到request_queue中；
2、request_queue實際上是一個表結構，"行"是fd、"列"是具體的請求。也就是說，同一個fd的請求會被組織在一起；
3、異步請求有優先級概念，屬於同一個fd的請求會按優先級排序，並且最終被按優先級順序處理；
4、隨著異步請求的提交，一些異步處理線程被動態創建。這些線程要做的事情就是從request_queue中取出請求，然後處理之；
5、為避免異步處理線程之間的競爭，同一個fd所對應的請求只由一個線程來處理；
6、異步處理線程同步地處理每一個請求，處理完成後在對應的aiocb中填充結果，然後觸發可能的信號通知或回調函數（回調函數是需要創建新線程來調用的）；
7、異步處理線程在完成某個fd的所有請求後，進入閑置狀態；
8、異步處理線程在閑置狀態時，如果request_queue中有新的fd加入，則重新投入工作，去處理這個新fd的請求（新fd和它上一次處理的fd可以不是同一個）；
9、異步處理線程處於閑置狀態一段時間後（沒有新的請求），則會自動退出。等到再有新的請求時，再去動態創建；
看起來，換作是我們，要在用戶態實現一個異步IO，似乎大概也會設計成類似的樣子……
linux版本
接口
下面再來看看linux版本的異步IO。它主要包含如下系統調用接口：
int io_setup(int maxevents, io_context_t *ctxp); /* 創建一個異步IO上下文（io_context_t是一個句柄） */
int io_destroy(io_context_t ctx); /* 銷毀一個異步IO上下文（如果有正在進行的異步IO，取消並等待它們完成） */
long io_submit(aio_context_t ctx_id, long nr, struct iocb **iocbpp); /* 提交異步IO請求 */
long io_cancel(aio_context_t ctx_id, struct iocb *iocb, struct io_event *result); /* 取消一個異步IO請求 */
long io_getevents(aio_context_t ctx_id, long min_nr, long nr, struct io_event *events, struct timespec *timeout) /* 等待並獲取異步IO請求的事件（也就是異步請求的處理結果） */
其中，struct iocb主要包含以下字段：
__u16 aio_lio_opcode; /* 請求類型（如：IOCB_CMD_PREAD=讀、IOCB_CMD_PWRITE=寫、等） */
__u32 aio_fildes; /* 要被操作的fd */
__u64 aio_buf; /* 讀寫操作對應的內存buffer */
__u64 aio_nbytes; /* 需要讀寫的字節長度 */
__s64 aio_offset; /* 讀寫操作對應的文件偏移 */
__u64 aio_data; /* 請求可攜帶的私有數據（在io_getevents時能夠從io_event結果中取得） */
__u32 aio_flags; /* 可選IOCB_FLAG_RESFD標記，表示異步請求處理完成時使用eventfd進行通知（百度一下） */
__u32 aio_resfd; /* 有IOCB_FLAG_RESFD標記時，接收通知的eventfd */
其中，struct io_event主要包含以下字段：
__u64 data; /* 對應iocb的aio_data的值 */
__u64 obj; /* 指向對應iocb的指針 */
__s64 res; /* 對應IO請求的結果（>=0: 相當於對應的同步調用的返回值；<0: -errno） */
實現
io_context_t句柄在內核中對應一個struct kioctx結構，用來給一組異步IO請求提供一個上下文。其主要包含以下字段：
struct mm_struct* mm; /* 調用者進程對應的內存管理結構（代表了調用者的虛擬地址空間） */
unsigned long user_id; /* 上下文ID，也就是io_context_t句柄的值（等於ring_info.mmap_base） */
struct hlist_node list; /* 屬於同一地址空間的所有kioctx結構通過這個list串連起來，鏈表頭是mm->ioctx_list */
wait_queue_head_t wait; /* 等待隊列（io_getevents系統調用可能需要等待，調用者就在該等待隊列上睡眠） */
int reqs_active; /* 進行中的請求數目 */
struct list_head active_reqs; /* 進行中的請求隊列 */
unsigned max_reqs; /* 最大請求數（對應io_setup調用的int maxevents參數） */
struct list_head run_list; /* 需要aio線程處理的請求列表（某些情況下，IO請求可能交給aio線程來提交） */
struct delayed_work wq; /* 延遲任務隊列（當需要aio線程處理請求時，將wq掛入aio線程對應的請求隊列） */
struct aio_ring_info ring_info; /* 存放請求結果io_event結構的ring buffer */
其中，這個aio_ring_info結構比較值得一提，它是用於存放請求結果io_event結構的ring buffer。它主要包含了如下字段：
unsigned long mmap_base; /* ring buffer的地始地址 */
unsigned long mmap_size; /* ring buffer分配空間的大小 */
struct page** ring_pages; /* ring buffer對應的page數組 */
long nr_pages; /* 分配空間對應的頁面數目（nr_pages * PAGE_SIZE = mmap_size） */
unsigned nr, tail; /* 包含io_event的數目及存取遊標 */
這個數據結構看起來有些奇怪，直接弄一個io_event數組不就完事了麽？為什麽要維護mmap_base、mmap_size、ring_pages、nr_pages這麽復雜的一組信息，而又把io_event結構隱藏起來呢？
這裏的奇妙之處就在於，io_event結構的buffer是在用戶態地址空間上分配的。註意，我們在內核裏面看到了諸多數據結構都是在內核地址空間上分配的，因為這些結構都是內核專有的，沒必要給用戶程序看到，更不能讓用戶程序去修改。而這裏的io_event卻是有意讓用戶程序看到，而且用戶就算修改了也不會對內核的正確性造成影響。於是這裏使用了這樣一個有些取巧的辦法，由內核在用戶態地址空間上分配buffer。（如果換一個保守點的做法，內核態可以維護io_event的buffer，然後io_getevents的時候，將對應的io_event復制一份到用戶空間。）
按照這樣的思路，io_setup時，內核會通過mmap在對應的用戶空間分配一段內存，mmap_base、mmap_size就是這個內存映射對應的位置和大小。然後，光有映射還不行，還必須立馬分配物理內存，ring_pages、nr_pages就是分配好的物理頁面。（因為這些內存是要被內核直接訪問的，內核會將異步IO的結果寫入其中。如果物理頁面延遲分配，那麽內核訪問這些內存的時候會發生缺頁異常。而處理內核態的缺頁異常又很麻煩，所以還不如直接分配物理內存的好。其二，內核在訪問這個buffer裏的信息時，也並不是通過mmap_base這個虛擬地址去直接訪問的。既然是異步，那麽結果寫回的時候可能是在另一個上下文上面，虛擬地址空間都不同。為了避免進行虛擬地址空間的切換，內核幹脆直接通過kmap將ring_pages映射到高端內存上去訪問好了。）
然後，在mmap_base指向的用戶空間的地址上，會存放著一個struct aio_ring結構，用來管理這個ring buffer。其主要包含了如下字段：
unsigned id; /* 等於aio_ring_info中的user_id */
unsigned nr; /* 等於aio_ring_info中的nr */
unsigned head,tail; /* io_events數組的遊標 */
unsigned magic,compat_features,incompat_features;
unsigned header_length; /* aio_ring結構的大小 */
struct io_event io_events[0]; /* io_event的buffer */
終於，我們期待的io_event數組出現了。
看到這裏，如果前面的內容你已經理解清楚了，你一定會有個疑問：既然整個aio_ring結構及其中的io_event緩沖都是放在用戶空間的，內核還提供io_getevents系統調用幹什麽？用戶程序不是直接就可以取用io_event，並且修改遊標了麽（內核作為生產者，修改aio_ring->tail；用戶作為消費者，修改aio_ring->head）？我想，aio_ring之所以要放在用戶空間，其原本用意應該就是這樣的。
那麽，用戶空間如何知道aio_ring結構的地址（aio_ring_info->mmap_base）呢？其實kioctx結構中的user_id，也就是io_setup返回給用戶的io_context_t，就等於aio_ring_info->mmap_base。
然後，aio_ring結構中還有諸如magic、compat_features、incompat_features這樣的字段，用戶空間可以讀這些magic，以確定數據結構沒有被異常篡改。如果一切可控，那麽就自己動手、豐衣足食；否則就還是走io_getevents系統調用。而io_getevents系統調用通過aio_ring_info->ring_pages得到aio_ring結構，再將相應的io_event拷貝到用戶空間。
下面貼一段libaio中的io_getevents的代碼（前面提到過，linux版本的異步IO是由用戶態的libaio來封裝的）：
int io_getevents_0_4(io_context_t ctx, long min_nr, long nr, struct io_event * events, struct timespec * timeout){
struct aio_ring *ring;
ring = (struct aio_ring*)ctx;
if (ring==NULL || ring->magic != AIO_RING_MAGIC)
goto do_syscall;
if (timeout!=NULL && timeout->tv_sec == 0 && timeout->tv_nsec == 0) {
if (ring->head == ring->tail)
return 0;
}
do_syscall:
return __io_getevents_0_4(ctx, min_nr, nr, events, timeout);
}
其中確實用到了用戶空間上的aio_ring結構的信息，不過尺度還是不夠大。
以上就是異步IO的context的結構。那麽，為什麽linux版本的異步IO需要“上下文”這麽個概念，而glibc版本則不需要呢？
在glibc版本中，異步處理線程是glibc在調用者進程中動態創建的線程，它和調用者必定是在同一個虛擬地址空間中的。這裏已經隱含了“同一上下文”這麽個關系。
而對於內核來說，要面對的是任意的進程，任意的虛擬地址空間。當處理一個異步請求時，內核需要在調用者對應的地址空間中存取數據，必須知道這個虛擬地址空間是什麽。不過當然，如果設計上要想把“上下文”這個概念隱藏了也是肯定可以的（比如讓每個mm隱含一個異步IO上下文）。具體如何選擇，只是設計上的問題。
struct iocb在內核中又對應到struct kiocb結構，主要包含以下字段：
struct kioctx* ki_ctx; /* 請求對應的kioctx（上下文結構） */
struct list_head ki_run_list; /* 需要aio線程處理的請求，通過該字段鏈入ki_ctx->run_list */
struct list_head ki_list; /* 鏈入ki_ctx->active_reqs */
struct file* ki_filp; /* 對應的文件指針 */
void __user* ki_obj.user; /* 指向用戶態的iocb結構 */
__u64 ki_user_data; /* 等於iocb->aio_data */
loff_t ki_pos; /* 等於iocb->aio_offset */
unsigned short ki_opcode; /* 等於iocb->aio_lio_opcode */
size_t ki_nbytes; /* 等於iocb->aio_nbytes */
char __user * ki_buf; /* 等於iocb->aio_buf */
size_t ki_left; /* 該請求剩余字節數（初值等於iocb->aio_nbytes） */
struct eventfd_ctx* ki_eventfd; /* 由iocb->aio_resfd對應的eventfd對象 */
ssize_t (*ki_retry)(struct kiocb *); /*由ki_opcode選擇的請求提交函數*/
調用io_submit後，對應於用戶傳遞的每一個iocb結構，會在內核態生成一個與之對應的kiocb結構，並且在對應kioctx結構的ring_info中預留一個io_events的空間。之後，請求的處理結果就被寫到這個io_event中。
然後，對應的異步讀寫（或其他）請求就被提交到了虛擬文件系統，實際上就是調用了file->f_op->aio_read或file->f_op->aio_write（或其他）。也就是，在經歷磁盤高速緩存層、通用塊層之後，請求被提交到IO調度層，等待被處理。這個跟普通的文件讀寫請求是類似的。
在《linux文件讀寫淺析》中可以看到，對於非direct-io的讀請求來說，如果page cache不命中，那麽IO請求會被提交到底層。之後，do_generic_file_read會通過lock_page操作，等待數據最終讀完。這一點跟異步IO是背道而馳的，因為異步就意味著請求提交後不能等待，必須馬上返回。而對於非direct-io的寫請求，寫操作一般僅僅是將數據更新作用到page cache上，並不需要真正的寫磁盤。page cache寫回磁盤本身是一個異步的過程。可見，對於非direct-io的文件讀寫，使用linux版本的異步IO接口完全沒有意義（就跟使用同步接口效果一樣）。
為什麽會有這樣的設計呢？因為非direct-io的文件讀寫是只跟page cache打交道的。而page cache是內存，跟內存打交道又不會存在阻塞，那麽也就沒有什麽異步的概念了。至於讀寫磁盤時發生的阻塞，那是page cache跟磁盤打交道時發生的事情，跟應用程序又沒有直接關系。
然而，對於direct-io來說，異步則是有意義的。因為direct-io是應用程序的buffer跟磁盤的直接交互（不使用page cache）。
這裏，在使用direct-io的情況下，file->f_op->aio_{read,write}提交完IO請求就直接返回了，然後io_submit系統調用返回。（見後面的執行流程。）
通過linux內核異步觸發的IO調度（如：被時鐘中斷觸發、被其他的IO請求觸發、等），已經提交的IO請求被調度，由對應的設備驅動程序提交給具體的設備。對於磁盤，一般來說，驅動程序會發起一次DMA。然後又經過若幹時間，讀寫請求被磁盤處理完成，CPU將收到表示DMA完成的中斷信號，設備驅動程序註冊的處理函數將在中斷上下文中被調用。這個處理函數會調用end_request函數來結束這次請求。這個流程跟《linux文件讀寫淺析》中所說的非direct-io讀操作的情況是一樣的。
不同的是，對於同步非direct-io，end_request將通過清除page結構的PG_locked標記來喚醒被阻塞的讀操作流程，異步IO和同步IO效果一樣。而對於direct-io，除了喚醒被阻塞的讀操作流程（同步IO）或io_getevents流程（異步IO）之外，還需要將IO請求的處理結果填回對應的io_event中。
最後，等到調用者調用io_getevents的時候，就能獲取到請求對應的結果（io_event）。而如果調用io_getevents的時候結果還沒出來，流程也會被阻塞，並且會在direct-io的end_request過程中得到喚醒。
linux版本的異步IO也有aio線程（每CPU一個），但是跟glibc版本中的異步處理線程不同，這裏的aio線程是用來處理請求重試的。某些情況下，file->f_op->aio_{read,write}可能會返回-EIOCBRETRY，表示需要重試（只有一些特殊的IO設備會這樣）。而調用者既然使用的是異步IO接口，肯定不希望裏面會有等待/重試的邏輯。所以，如果遇到-EIOCBRETRY，內核就在當前CPU對應的aio線程添加一個任務，讓aio線程來完成請求的重新提交。而調用流程可以直接返回，不需要阻塞。
請求在aio線程中提交和在調用者進程中提交相比，有一個最大的不同，就是aio線程使用的地址空間可能跟調用者線程不一樣。需要利用kioctx->mm切換到正確的地址空間，然後才能發請求。（參見《淺嘗異步IO》中的討論。）
內核處理流程
最後，整理一下direct-io異步讀操作的處理流程：
io_submit。對於提交的iocbpp數組中的每一個iocb（異步請求），調用io_submit_one來提交它們；
io_submit_one。為請求分配一個kiocb結構，並且在對應的kioctx的ring_info中為它預留一個對應的io_event。然後調用aio_rw_vect_retry來提交這個讀請求；
aio_rw_vect_retry。調用file->f_op->aio_read。這個函數通常是由generic_file_aio_read或者其封裝來實現的；
generic_file_aio_read。對於非direct-io，會調用do_generic_file_read來處理請求（見《linux文件讀寫淺析》）。而對於direct-io，則是調用mapping->a_ops->direct_IO。這個函數通常就是blkdev_direct_IO；
blkdev_direct_IO。調用filemap_write_and_wait_range將相應位置可能存在的page cache廢棄掉或刷回磁盤（避免產生不一致），然後調用direct_io_worker來處理請求；
direct_io_worker。一次讀可能包含多個讀操作（對應於類readv系統調用），對於其中的每一個，調用do_direct_IO；
do_direct_IO。調用submit_page_section；
submit_page_section。調用dio_new_bio分配對應的bio結構，然後調用dio_bio_submit來提交bio；
dio_bio_submit。調用submit_bio提交請求。後面的流程就跟非direct-io是一樣的了，然後等到請求完成，驅動程序將調用 bio->bi_end_io來結束這次請求。對於direct-io下的異步IO，bio->bi_end_io等於dio_bio_end_aio；
dio_bio_end_aio。調用wake_up_process喚醒被阻塞的進程（異步IO下，主要是io_getevents的調用者）。然後調用aio_complete；
aio_complete。將處理結果寫回到對應的io_event中；
比較
從上面的流程可以看出，linux版本的異步IO實際上只是利用了CPU和IO設備可以異步工作的特性（IO請求提交的過程主要還是在調用者線程上同步完成的，請求提交後由於CPU與IO設備可以並行工作，所以調用流程可以返回，調用者可以繼續做其他事情）。相比同步IO，並不會占用額外的CPU資源。
而glibc版本的異步IO則是利用了線程與線程之間可以異步工作的特性，使用了新的線程來完成IO請求，這種做法會額外占用CPU資源（對線程的創建、銷毀、調度都存在CPU開銷，並且調用者線程和異步處理線程之間還存在線程間通信的開銷）。不過，IO請求提交的過程都由異步處理線程來完成了（而linux版本是調用者來完成的請求提交），調用者線程可以更快地響應其他事情。如果CPU資源很富足，這種實現倒也還不錯。
還有一點，當調用者連續調用異步IO接口，提交多個異步IO請求時。在glibc版本的異步IO中，同一個fd的讀寫請求由同一個異步處理線程來完成。而異步處理線程又是同步地、一個一個地去處理這些請求。所以，對於底層的IO調度器來說，它一次只能看到一個請求。處理完這個請求，異步處理線程才會提交下一個。而內核實現的異步IO，則是直接將所有請求都提交給了IO調度器，IO調度器能看到所有的請求。請求多了，IO調度器使用的類電梯算法就能發揮更大的功效。請求少了，極端情況下（比如系統中的IO請求都集中在同一個fd上，並且不使用預讀），IO調度器總是只能看到一個請求，那麽電梯算法將退化成先來先服務算法，可能會極大的增加碰頭移動的開銷。
最後，glibc版本的異步IO支持非direct-io，可以利用內核提供的page cache來提高效率。而linux版本只支持direct-io，cache的工作就只能靠用戶程序來實現了。
linux異步IO的兩種方式【轉】