>>>>> " " == Linus Torvalds <torvalds@transmeta.com> writes:
> I suspect, but I'll let Trond answer this, that Trond just
> wanted to avoid letting pending read-aheads pass past the
> vmtruncate(). It definitely does nothing for the block device
> layer, and I suspect that it doesn't much help on NFS either,
> except for forcing some ordering of the NFS requests that
> shouldn't be required..
> Trond?
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 main idea is to try to reduce the effect on memory of frequent
calls to invalidate_inode_pages() something which can be a problem
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.
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
page is up to date and has no buffers, then we can skip the
run_task_queue()?
Cheers,
Trond
-
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:12 EST