From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 5 Feb 2006 20:50:56 -0800 From: Andrew Morton Subject: Re: [VM PATCH] rotate_reclaimable_page fails frequently Message-Id: <20060205205056.01a025fa.akpm@osdl.org> In-Reply-To: References: <20060205150259.1549.qmail@web33007.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Rik van Riel Cc: sgoel01@yahoo.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: Rik van Riel wrote: > > On Sun, 5 Feb 2006, Shantanu Goel wrote: > > > It seems rotate_reclaimable_page fails most of the > > time due the page not being on the LRU when kswapd > > calls writepage(). > > The question is, why is the page not yet back on the > LRU by the time the data write completes ? Could be they're ext3 pages which were written out by kjournald. Such pages are marked dirty but have clean buffers. ext3_writepage() will discover that the page is actually clean and will mark it thus without performing any I/O. In which case this code in shrink_list(): /* * A synchronous write - probably a ramdisk. Go * ahead and try to reclaim the page. */ if (TestSetPageLocked(page)) goto keep; if (PageDirty(page) || PageWriteback(page)) goto keep_locked; mapping = page_mapping(page); case PAGE_CLEAN: ; /* try to free the page below */ should just go and reclaim the page immediately. Shantanu, I suggest you add some instrumentation there too, see if it's working. (That'll be non-trivial. Just because we hit PAGE_CLEAN: here doesn't necessarily mean that the page will be reclaimed). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org