On Thu, Jan 15, 2009 at 10:24 PM, Matthew Wilcox <matthew@xxxxxx> wrote: > On Thu, Jan 15, 2009 at 09:50:57PM +0530, Manish Katiyar wrote: >> On Thu, Jan 15, 2009 at 7:30 PM, Matthew Wilcox <matthew@xxxxxx> wrote: >> > On Thu, Jan 15, 2009 at 02:50:27PM +0100, Francis Moreau wrote: >> >> Let's say that a process wants to read a page of data stored in a file. >> >> For that it issues a sys_read(). >> >> >> >> Now the data page is not in the page cache and it must be fetched from >> >> the disk. >> >> >> >> So I assume while the data page is recovered from the disk, the process >> >> is suspended until the data are ready to be read. >> >> >> >> Could anybody show me where in the source code where the process is >> >> suspended ? >> >> I might be wrong, because I am a newbie too.......but still i will >> try. I think it follows the below path. >> >> do_generic_file_read() -> find_get_page() (This tries to find the >> required page in cache). If we don't find here we try to do a >> readahead using page_cache_sync_readahead() and then we eventually >> call mpage_readpage() -> do_mpage_readpage() and then we put it in the >> cache using add_to_page_cache_lru(). >> >> Please correct me if I am wrong. > > You're not wrong, but you aren't answering his question. He asked where > the process is suspended, and the answer is "in __lock_page_killable()". Thanks a lot. thanks - Manish > >> Thanks - >> Manish >> >> > >> > Sure. Take a look in mm/filemap.c. Filesystems that use the page cache >> > will usually end up calling do_generic_file_read() one way or another. >> > It tries to find the page in the page cache, when it doesn't find the >> > page, it creates it, then calls ->readpage() to start the read, and >> > lock_page_killable() to wait for the page to be read. As the comment >> > says, when the read finishes, it will unlock the page and the reader >> > will continue. >> > >> > -- >> > Matthew Wilcox Intel Open Source Technology Centre >> > "Bill, look, we understand that you're interested in selling us this >> > operating system, but compare it to ours. We can't possibly take such >> > a retrograde step." >> > -- >> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in >> > the body of a message to majordomo@xxxxxxxxxxxxxxx >> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > Matthew Wilcox Intel Open Source Technology Centre > "Bill, look, we understand that you're interested in selling us this > operating system, but compare it to ours. We can't possibly take such > a retrograde step." > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
