DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id;
  b=JvveS2JaYamUmY3qW36AvoKGtGy+6r1IaWRl3gzCpGYPg854JNwN2uMt65NJl+ba7CG5gj4h1Fm6lKMhTBP4Rw3gr0POg57vvpgKxAgLDMP/SbWjmuSDZmmgm5LTvny1hyA4KlqL6uCAIUd+jJ1ULw5BbiQy2oy/GZ/0WzCfHaA=  ;
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: David Howells <dhowells@redhat.com>
Subject: Re: [PATCH 23/43] CacheFiles: Permit the page lock state to be monitored [ver #46]
Date: Fri, 3 Apr 2009 03:35:12 +1100
User-Agent: KMail/1.9.51 (KDE/4.0.4; ; )
Cc: viro@zeniv.linux.org.uk, nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org,
       linux-fsdevel@vger.kernel.org
References: <200904030237.25893.nickpiggin@yahoo.com.au> <20090401230520.28177.61387.stgit@warthog.procyon.org.uk> <6638.1238688892@redhat.com>
In-Reply-To: <6638.1238688892@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200904030335.13439.nickpiggin@yahoo.com.au>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1699
Lines: 38

On Friday 03 April 2009 03:14:52 David Howells wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> > I prefer to nack this because it is exporting details of the page
> > locking mechanism. unlock_page is very heavyweight in large part
> > because of the memory barriers and cacheline required to check the
> > waitqueue. I have patches to avoid all that if the page lock is
> > not contended.
> > 
> > What's wrong with using wait_on_page_locked, like everyone else does?
> 
> When fscache_read_or_alloc_pages() is called from, say, nfs_readpages(), and is
> given a few hundred pages to readahead from the cache, who does the
> wait_on_page_locked() on each of the _backing_ fs's pages?

Presumably: at the point where data is needed.


> The way I've arranged things to work is for the backing fs pages to be copied
> to the netfs pages and released in the order they're read from the disk.
> 
> There's a small pool of threads that processes the pages.  I don't want to have
> to create a thread for each readpages(), and I don't want readpages() to have
> to wait for all the requests it makes.

Or do you actually have numbers showing a problem if you just read the pages
then copy them?


If there is a problem, then why doesn't fscache_read_or_alloc_pages caller do
the work itself, then you get as many threads as you have indivisible work units,
so completing some part of the request before another wouldn't gain you anything
anyway...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/