page_cache_async_readahead如何实现异步读取的
本帖最后由 arm-linux-gcc 于 2015-01-21 09:55 编辑并没有看到在什么地方开启了别的线程或workqueue
我看到走到read_pages里面，会在blk_finish_plug处对提交的那些request调用__blk_run_queue，而__blk_run_queue中是直接调用的块设备驱动注册下去的request_fn回调了
请问page_cache_async_readahead的”后台读“体现在那里？
难道是要依靠块设备驱动的request_fn回调自己主动去wake_up另外一个线程来做真正的读取物理介质？比如mmc_request_fn wake_up了mmc_queue_thread
本帖最后由 arm-linux-gcc 于 2015-01-20 22:57 编辑
@blake326 本帖最后由 embeddedlwp 于 2015-01-21 06:53 编辑
sync readahead on page cache cache miss
async readahead on reach threshold for readahead pipelining
本帖最后由 arm-linux-gcc 于 2015-01-21 09:53 编辑
回复 3# embeddedlwp
你没看明白我问的问题，我知道page_cache_sync_readahead读的是未命中的page（也就是app想要的那些数据），page_cache_async_readahead读的是设置了readahead后面的那些page（此时app想要的数据已经在page cache里了，这次只是为了下一轮的app read准备数据）
但是我没看明白page_cache_async_readahead的后台操作是怎么实现的，整个流程看一下一直到块设备的request_fn，都在同一个线程上，
如果块设备的request_fn里直接就做了真正的读介质操作（而不是启动另外一个线程来做），那么request_fn没读完数据前page_cache_async_readahead是不能返回的，那么这次do_generic_file_read就无法实现“直接从page cache里取数据，并且后台预读将来的数据”了，于是看到的就将会是“这次想要的数据在page cache里，但是仍然要等到预读将来的数据完成之后，read系统调用才能返回”，
这显然不合理，看上去后台读取能否实现就完全取决于request_fn怎么写了。
不知道我的理解对不对。
arm-linux-gcc 发表于 2015-01-21 09:49 static/image/common/back.gif
回复 3# embeddedlwp
个人理解：
IO(包括读)操作本身就是异步的，这里的sync实际并非真正意义上的同步，page_cache_async_readahead和page_cache_sync_readahead实际都是异步读，异步体现在read_pages之后，最终实际是将IO request提交到相应的请求队列后，就直接返回了，并没有阻塞等待IO完成，最终IO request的提交还依赖于kblockd之类的机制对请求队列进行unplug，然后将请求提交到底层，底层完成IO请求后通过中断和endio来通知上层，IO request的执行实际是异步完成的。
page_cache_sync_readahead的“同步”，体现在do_generic_file_read中调用page_cache_sync_readahead后，会通过lock_page_killable(page)同步等待“需要读取的”page的读操作完成，而此时该page的读请求是和其它预读的pages通过page_cache_sync_readahead一起下发的。
回复 5# humjb_1983
楼上正解:mrgreen:
页:
[1]