From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Address space operations questions Date: Thu, 31 Mar 2005 16:53:59 -0500 Message-ID: <1112306039.12906.44.camel@lade.trondhjem.org> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Zach Brown , Linux Filesystem Development , Nikita Danilov Return-path: Received: from pat.uio.no ([129.240.130.16]:41158 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S261573AbVCaVyV (ORCPT ); Thu, 31 Mar 2005 16:54:21 -0500 To: Bryan Henderson In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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