From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <451D8371.2070101@oracle.com> Date: Fri, 29 Sep 2006 16:34:57 -0400 From: Chuck Lever Reply-To: chuck.lever@oracle.com MIME-Version: 1.0 Subject: Re: Checking page_count(page) in invalidate_complete_page References: <4518333E.2060101@oracle.com> <20060925141036.73f1e2b3.akpm@osdl.org> <45185D7E.6070104@yahoo.com.au> <451862C5.1010900@oracle.com> <45186481.1090306@yahoo.com.au> <45186DC3.7000902@oracle.com> <451870C6.6050008@yahoo.com.au> <4518835D.3080702@oracle.com> <451886FB.50306@yahoo.com.au> <451BF7BC.1040807@oracle.com> <20060928093640.14ecb1b1.akpm@osdl.org> <20060928094023.e888d533.akpm@osdl.org> <451BFB84.5070903@oracle.com> <20060928100306.0b58f3c7.akpm@osdl.org> <451C01C8.7020104@oracle.com> <451C6AAC.1080203@yahoo.com.au> In-Reply-To: <451C6AAC.1080203@yahoo.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Andrew Morton , Trond Myklebust , Steve Dickson , linux-mm@kvack.org List-ID: Nick Piggin wrote: > Chuck Lever wrote: > >> Andrew Morton wrote: >> >>> lru_add_drain_all() is a nasty, hacky, not-exported-to-modules >>> thing. It >>> equates to lru_add_drain() if !CONFIG_NUMA. >> > > It should drain on all CPUs though, I can't remember why it doesn't. > Not that I disagree that throwing IPIs around is a hack ;) > >>> Sigh, we're not getting there, are we? >>> >>> I'm still thinking we add invalidate_complete_page2() to get us out of >>> trouble and park the problem :(. That'd be a good approach for >>> 2.6.18.x, >>> which I assume is fairly urgent. >> >> >> Choosing which fix to include is above my pay grade. Both of these >> proposals address the NFS readdir cache invalidation problem. >> >> But it seems like there is a real problem here -- the pages that are >> waiting to be added the LRU will always have a page count that is too >> high for invalidate_inode_pages to work on them. One option that hasn't been entertained is to remove the "batched LRU add" logic all together. Just gut lru_cache_add -- it should send pages immediately to be added to the LRU list. This is a bit slower, but it fixes the invalidation problems, and makes the icky lru_add_drain_all() a no-op. Note that lru_add_drain_all() would have to be called much more often if it is called from the inode invalidation logic... So, which is more overhead, adding a page to the LRU at a time, or draining the per-CPU LRU pagevecs all the time? > If you do the lru_add_drain_all, then the vmscan problem should be probably > mostly fixable by detecting failure, waiting, and retrying a few times. Why shouldn't invalidate_complete_pages() do that? > After that, making an invalidate_complete_page2 ignore the page count or > dirty status would only save you from a very small number of cases, and > they > would be likely to be a data loss / corruption case. > > OTOH, we haven't had many complaints before, so for 2.6.18, an > invalidate_complete_page2 may indeed be the best option? -- 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