I was wrong on this topic, the reading process sleeps on the do_generic_mapping_read(), when it needs actually read from disk. It is mapping->a_ops->readpage(filp, page). This function submits a request and return. Then, if the page is not up to date, the process will turn to sleep until the bio->bi_end_io is called to unlock the page and wakes up all processors waiting for this page. So, I was totally wrong on my guess. Fawad's thinking is more close to the facts. On Sun, 30 Oct 2005, Hui Cheng wrote: > > The end_io function for read is bio->bi_end_io, which corresponds to > mpage_end_io_read. In this function, it only checks if the pages in the > bio are up to date, because it is possible that the read has been finished > at now. But if not, the page is set a PG_error. after each page is > checked, whole function return. For the ide_do_request, it enables the > iterrupt for ide disk intr. Your citation of the "take short snooze"just > says that there should be a fair chance for multiple hwgroups, so give it > a little idle time to make others have chance to run. it is a hardware > sleep not a process sleep. Thank Fawad for your help, anybody could help > giving a final conclusion? > > > On Sun, 30 Oct 2005, Fawad Lateef wrote: > > > On 10/30/05, Hui Cheng <hcheng@xxxxxxxxxxx> wrote: > > > > > > I went through the floppy code you mentioned, yes, it works as you said. > > > But the problem is, I don't think that the ide disk works the similar way. > > > In linux 2.4 kernel, the reading process explicitly sleep at > > > do_generic_file_read()->wait_on_page(), that is why the coder try > > > everything to postpone calling wait_on_page. However, I think things > > > change in 2.6. I have a guess that the synchronous read has been improved > > > by some asynchronous method. That is, the process (which performs a > > > synchronous read) just submit a synchronous read request and return, even > > > though the buffer is not filled with data from disk. It would turn to > > > sleep only when it performs real operating on the buffer (if the buffer > > > is still not filled in valid data by then). In this way, the > > > performance is improved. That is why I did not find any "put to sleeo > > > code" in the file system and ide driver code. But this is only my guess. > > > Any suggestion? And thanks Fawad for your kindly reply:) > > > > > > > I don't think your guess is right ! When we do read from user-space > > application, through system call sys_read is called which goes to the > > vfs_read and then goes to the file-system read function which calls > > the submit_bio to submit request to device and get signal in the form > > of end_io when the device completes request. Now as your guess is the > > data in buffer isn't present till the operation on the buffer is done > > is not seems valid to me. Because I saw sleeping variable, timer etc > > in ide-io.c code especially in ide_do_request function which I think > > is used for sleeping (I havn't got into the datail of it) as the > > comments in ide_do_request function says : (see > > http://lxr.linux.no/source/drivers/ide/ide-io.c#L1074) > > > > /* > > * Take a short snooze, and then wake up this hwgroup again. > > * This gives other hwgroups on the same a chance to > > * play fairly with us, just in case there are big differences > > * in relative throughputs.. don't want to hog the cpu too much. > > */ > > > > And after fullfiling the request ide driver also calls ide_end_request > > which at-last call blk_dequeue_request and end_that_request_last .... > > > > By the way, Now I am also giving-up and now wait for some-other > > person's response, if there is some-thing missing in my understanding > > or I am wrong ! > > > > > > -- > > Fawad Lateef > > > > -- > > Kernelnewbies: Help each other learn about the Linux kernel. > > Archive: http://mail.nl.linux.org/kernelnewbies/ > > FAQ: http://kernelnewbies.org/faq/ > > > > > > > -- > Kernelnewbies: Help each other learn about the Linux kernel. > Archive: http://mail.nl.linux.org/kernelnewbies/ > FAQ: http://kernelnewbies.org/faq/ > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/