From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: Re: [PATCH 30/45] vmscan: lumpy pageout Date: Wed, 7 Oct 2009 21:29:24 +0800 Message-ID: <20091007132924.GB20855@localhost> References: <8acda98c0910070338n7220fdabo8c7f8f9e7d21ef6c@mail.gmail.com> <20091007111454.GB15936@localhost> <8acda98c0910070437g1498f99eua9a5ad71e6c2bae4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andrew Morton , Theodore Tso , Christoph Hellwig , Dave Chinner , Chris Mason , Peter Zijlstra , "Li, Shaohua" , Myklebust Trond , "jens.axboe@oracle.com" , Jan Kara , Nick Piggin , "linux-fsdevel@vger.kernel.org" To: Nikita Danilov Return-path: Received: from mga03.intel.com ([143.182.124.21]:63161 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933639AbZJGNaV (ORCPT ); Wed, 7 Oct 2009 09:30:21 -0400 Content-Disposition: inline In-Reply-To: <8acda98c0910070437g1498f99eua9a5ad71e6c2bae4@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Oct 07, 2009 at 07:37:35PM +0800, Nikita Danilov wrote: > 2009/10/7 Wu Fengguang : > > On Wed, Oct 07, 2009 at 06:38:37PM +0800, Nikita Danilov wrote: > >> Hello, > >> >=20 > [...] >=20 > > > > Glad to know about your experiences :) Interestingly I started with > > ->writepage() and then switch to ->writepages() because filesystems > > behave better with the latter (i.e. less file fragmentation). >=20 > By the way, why is your patch doing >=20 > ->writepage(page->index); > generic_writepages(page->index + 1, LUMPY_PAGEOUT_PAGES - 1); >=20 > instead of >=20 > generic_writepages(page->index, LUMPY_PAGEOUT_PAGES); >=20 > ? Is this because of the difficulties with passing back page specific > errors from generic_writepages()? Yes. It's possible to tell write_cache_pages() to return AOP_WRITEPAGE_ACTIVATE. Other ->writepages() don't have to deal with this because their ->writepage() won't return AOP_WRITEPAGE_ACTIVATE at all. But it is going to be ugly to specialize the first locked page in every ->writepages() functions.. > > > > I'd like to just ignore the shmem case, by adding a > > bdi_cap_writeback_dirty() check. Because clustered writing to swap > > device may be a less gain. >=20 > Or you can just call try_to_unmap() from shmem_writepage() when > wbc->for_reclaim is true. Hmm, it's more comfortable to stay away from shmem for the initial vers= ion. But feel free to submit a patch for it in future :) > > Page filtering should also be possible in write_cache_pages(). =C2=A0= But > > what do you mean by "hard-to-fix races against inode reclamation"? >=20 > vmscan.c pageout path doesn't take a reference on inode, so the > instant ->writepage() releases lock on the page, the inode can be > freed. Ah, then we could just do igrab() if inode_lock is not locked? A bit ugly though. Thanks, =46engguang -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html