page_cache_async_readahead的page lock是在哪里做的？
page_cache_async_readahead最后会调用blk_finish_plug将request提交给内核request执行完之后我看到在mpage_end_io回调里面会unlock_page
那么开始执行这个request之前，lock_page是在什么地方做的？
我找了很久都没找到
应该是在调用者函数中，比如：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。 回复 3# 镇水铁牛
非常感谢，原来这么早就就lock了，我原来还以为要等到从request_queue里取出request时才会lock 回复 4# arm-linux-gcc
我上面回复的后半句是针对IO写流程的。page的写流程中，会在两个地方lock，第一次lock的时机确实很靠前。 回复 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提交到磁盘驱动维护的请求队列中。
页:
[1]