page_cache_async_readahead的page lock是在哪里做的？

arm-linux-gcc

page_cache_async_readahead最后会调用blk_finish_plug将request提交给内核

request执行完之后我看到在mpage_end_io回调里面会unlock_page

那么开始执行这个request之前，lock_page是在什么地方做的？
我找了很久都没找到

humjb_1983

应该是在调用者函数中，比如：do_generic_file_read中

镇水铁牛

刚才跟了下代码：
do_generic_file_read中如果要读的数据不在page cache中，会page_cache_sync_readahead，直到调用add_to_page_cache_lru，里面就会lock page，当set page writeback后，会unlock page。

arm-linux-gcc

回复 3# 镇水铁牛


    非常感谢，原来这么早就就lock了，我原来还以为要等到从request_queue里取出request时才会lock

镇水铁牛

回复 4# arm-linux-gcc


    我上面回复的后半句是针对IO写流程的。page的写流程中，会在两个地方lock，第一次lock的时机确实很靠前。

arm-linux-gcc

回复 5# 镇水铁牛


    请问另外一次是在那里呢？

镇水铁牛

在blcok层：
        以buffer io为例，常规的写需要执行3步：write_begin---copy_data---write_end
        write_begin主要是在address_space查找该page，如果找到则lock，没找到则分配一个page，并lock。   
        copy_data为常规的用户态数据copy到内核中，访问page时需要kmap。
        write_end则目的是更新buffer_head，page， inode的状态（主要是标脏），并unlock该page.
        然后**pdflush，此时，异步IO就返回了。
在scsi层：
        当dirty page数量大于阈值、或者dirty page在内存中存在过长时间，pdflush会被激活。
        首先遍历所有dirty的inode，然后依次回写mapping中的数据到设备中。
        在write_cache_pages中，lock page后，直到调用__block_write_full_page，遍历出脏缓冲区，set_page_writeback。
        之后submit_bh，unlock page，但此时bh已经被lock，设置回调end_bio_bh_io_sync。
        之后submit_bio，将bio提交到磁盘驱动维护的请求队列中。