Re: Where does a process wait after requesting some data file ?

[Matthew Wilcox <matthew@wil.cx>]

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@wil.cx> 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 -
> 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@vger.kernel.org
> > 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@vger.kernel.org
> 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."