On 27 Apr 2000, Trond Myklebust wrote:
>Actually that particular call is more for the benefit of writebacks:
>Once we get to remove_inode_page() we hold the pagelock, hence we know
>that there are no pending readaheads on the page. There can however be
>pending writes.
The buffers heads overlapped on the page cache can be dirty but we'll
clear the dirty bitflag in the same critical section. The thing that does
the trick is unmap_buffer in these two lines:
mark_buffer_clean(bh);
wait_on_buffer(bh);
The order of the two lines is foundamental.
>The main idea is to try to reduce the effect on memory of frequent
>calls to invalidate_inode_pages() something which can be a problem
Could you explain me why NFS needs invalidate_inode_pages()? Is the cache
of the inodes supposed to be completly trimmed once we return from such
call? invalidate_inode_pages isn't safe with mapped pages and there must
be some highlevel design enforcement while calling it.
>under NFS. Of course the same concept applies to the xxtruncate()
>operations, so it seemed correct to me to put the call in
>remove_inode_page() rather than making invalidate_inode_pages() a
>special case.
The call in remove_inode_page() isn't necessary (at least for ext2) so
it's not correct.
The fact is that the design is to never use
run_task_queue(&tq_disk) directly. You get it by magic when it's necessary
if you use the wait_on_buffer() when you want to wait for I/O to complete.
>As for the disk-based case. Is there perhaps some test we can perform
>on the page in block_sync_page() in order to find out whether or not
>any IO is pending on that particular page? Perhaps if we see that the
We just do that in unmap_buffer.
>page is up to date and has no buffers, then we can skip the
>run_task_queue()?
That's how thing was just working.
I don't understand why nfs needs a special callback to startup on the NFS
server. Once the write got the ack that the write happend nfs shouldn't
need to do the additional sync. That call is necessary only for internal
driver unplugging. There's no such mechanism on a network socket.
ATM I believe we don't need the i_ops->sync_page callback.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:13 EST