All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2012-09-17 17:58 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.