to den 31.03.2005 Klokka 13:40 (-0800) skreiv Bryan Henderson: > >what it > >*really* means to be called in sync_page() is that you're being told > >that some process is about to block on that page. For what reason, you > >can't know from the call alone. > > Ugh. IOW it barely means anything.
It reflects the fact that the page lock can be held for a variety of reasons, some of which require you to kick the filesystem and some which don't. I introduced the sync_page() call in 2.4.x partly in order to get rid of all those pathetic hard-coded calls to "run_task_queue(&tq_disk)" that used to litter the 2.4.x mm code (and still do in some places). As far as NFS is concerned, they are a useless distraction since only the block code uses the tq_disk queue. The other reason was that the NFS client itself had to defer actually putting reads on the wire until someone requested the lock: the reason was that there was no equivalent of the "readpages()" call, so that when we wanted to coalesce more than 1 page worth of data into a single read call, we had to exit readpage() without actually starting I/O in the hope that the readahead code would then schedule a readpage() on a neighbouring page. Cheers, Trond -- Trond Myklebust <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
