From: Laura Abbott <lauraa@codeaurora.org>
To: Hugh Dickins <hughd@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
linaro-mm-sig@lists.linaro.org, linux-arm-msm@vger.kernel.org
Subject: Re: [RFC][PATCH] fs/buffer.c: Revoke LRU when trying to drop buffers
Date: Mon, 17 Sep 2012 10:57:59 -0700 [thread overview]
Message-ID: <505764A7.901@codeaurora.org> (raw)
In-Reply-To: <alpine.LSU.2.00.1209141821310.2138@eggly.anvils>
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
next prev parent reply other threads:[~2012-09-17 17:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 17:28 [RFC][PATCH] fs/buffer.c: Revoke LRU when trying to drop buffers Laura Abbott
2012-09-15 1:41 ` Hugh Dickins
2012-09-17 17:57 ` Laura Abbott [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-07-05 2:01 Damian Hobson-Garcia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=505764A7.901@codeaurora.org \
--to=lauraa@codeaurora.org \
--cc=hughd@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).