From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laura Abbott Subject: Re: [RFC][PATCH] fs/buffer.c: Revoke LRU when trying to drop buffers Date: Mon, 17 Sep 2012 10:57:59 -0700 Message-ID: <505764A7.901@codeaurora.org> References: <1347384529-5862-1-git-send-email-lauraa@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Marek Szyprowski , linaro-mm-sig@lists.linaro.org, linux-arm-msm@vger.kernel.org To: Hugh Dickins Return-path: In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, On 9/14/2012 6:41 PM, Hugh Dickins wrote: > On Tue, 11 Sep 2012, Laura Abbott wrote: >> When a buffer is added to the LRU list, a reference is taken which is >> not dropped until the buffer is evicted from the LRU list. This is the >> correct behavior, however this LRU reference will prevent the buffer >> from being dropped. This means that the buffer can't actually be dropped >> until it is selected for eviction. There's no bound on the time spent >> on the LRU list, which means that the buffer may be undroppable for >> very long periods of time. Given that migration involves dropping >> buffers, the associated page is now unmigratible for long periods of >> time as well. > > Disclaimer: I'm no expert on buffer_heads, and haven't studied your > patch. But it seems to me that this is an issue with the (unnamed) > filesystem you use, rather than a problem to be solved in drop_buffers(). > We are using ext4 > extN, gfs2, ntfs, ocfs2 and xfs set .migratepage = buffer_migrate_page, > and I cannot see that page migration involves drop_buffers() at all in > that case: it transfers the buffer_heads from the old page to the new, > whether they're busy or not, with no attempt to free them. > That's true for most of the address spaces EXCEPT for the journaled address space operations; ext4_ordered_aops, ext4_writeback_aops, ext4_da_aops all set migratepage but ext4_journalled_aops does not set migratepage at all. This seems to be true all the way back to when the migratepage was added for ext3. > Maybe your filesystem can be converted, with or without some extra help, > to buffer_migrate_page() instead of the default fallback_migrate_page(): > which indeed has to play safe, doing the try_to_release_page() you see. > Maybe ask on the mailing list for your filesystem? > I could ask on the ext mailing list for the historical reasons why the journalled ops don't have migrate pages, but I'm still going to assert this is still a problem with fallback_migrate_page. It's still possible to have drop_buffers fail unnecessarily because the buffer is stuck on the LRU list and I don't see why the problem shouldn't be fixed there as well. > Hugh > Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation