From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/4] xfs: cancel dirty pages on invalidation
Date: Wed, 11 Oct 2017 22:58:58 +1100 [thread overview]
Message-ID: <20171011115858.GZ3666@dastard> (raw)
In-Reply-To: <20171011090219.GA32909@bfoster.bfoster>
On Wed, Oct 11, 2017 at 05:02:20AM -0400, Brian Foster wrote:
> On Wed, Oct 11, 2017 at 11:04:00AM +1100, Dave Chinner wrote:
> > On Tue, Oct 10, 2017 at 08:29:45AM -0400, Brian Foster wrote:
> > > On Tue, Oct 10, 2017 at 07:48:16AM +1100, Dave Chinner wrote:
> > > > On Mon, Oct 09, 2017 at 10:24:46AM -0400, Brian Foster wrote:
> > > > > On Mon, Oct 09, 2017 at 10:54:14AM +1100, Dave Chinner wrote:
> > shrink_inactive_list
> > shrink_list
> > buffer_heads_over_limit
> > try_to_release_page
> > xfs_vm_releasepage()
> > xfs_count_page_state <<< finds delalloc/unwritten buffer
> > WARN_ON(delalloc)
> >
>
> The xfs_vm_releasepage() code looks like this:
>
> ...
> xfs_count_page_state(page, &delalloc, &unwritten);
>
> if (delalloc) {
> WARN_ON_ONCE(!PageDirty(page));
> return 0;
> }
> ...
>
> So if we get here with a dirty page over a delalloc extent, for example,
> how exactly does that trigger a spurious warning? AFAICT the warning
> will not trigger because the page is dirty. We decide not to release the
> page precisely because it has delalloc buffers.
And, you know, it's not until you pasted it here that I saw the
"!" in that WARN_ON_ONCE.
I've looked at repeatedly over many weeks, and not *once* have I
registered that it's a "NOT page dirty" warning.
So we can ignore the spurious warning issue. You're right, that
clearly doesn't happen.
But, realistically, we shouldn't be relying on bufferhead state to
determine what the correct action to take is. We can still have
dirty pages that do not have delalloc or unwritten extents on them
that we should not be attempting to free. The current code happily
hands them to try_to_free_buffers() rather than says "no, we don't
free dirty pages".
i.e. if xfs_invalidatepage() is trashing the dirty state on the
buffers, then we should also be trashing the dirty state on the page
so they are clean and coherent when passed to xfs_vm_releasepage.
That leaves us with the simple rule in xfs_vm_releasepage():
Never release a dirty page because they always contain valid
data that needs to be written back first.
That's what I'm trying to do - move the control decisions to page
level, rather than having them split and, at times, be incoherent
at bufferhead level. We're wanting to get rid of bufferheads so we
should be making decisions in this code based on page state, not
the bufferhead state...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-10-11 11:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-08 23:54 [PATCH 0/4] xfs: miscellaneous fixes Dave Chinner
2017-10-08 23:54 ` [PATCH 1/4] xfs: Don't log uninitialised fields in inode structures Dave Chinner
2017-10-09 14:24 ` Brian Foster
2017-10-08 23:54 ` [PATCH 2/4] xfs: move more RT specific code under CONFIG_XFS_RT Dave Chinner
2017-10-09 14:24 ` Brian Foster
2017-10-08 23:54 ` [PATCH 3/4] xfs: don't change inode mode if ACL update fails Dave Chinner
2017-10-09 14:24 ` Brian Foster
2017-10-08 23:54 ` [PATCH 4/4] xfs: cancel dirty pages on invalidation Dave Chinner
2017-10-09 14:24 ` Brian Foster
2017-10-09 20:48 ` Dave Chinner
2017-10-10 12:29 ` Brian Foster
2017-10-11 0:04 ` Dave Chinner
2017-10-11 9:02 ` Brian Foster
2017-10-11 11:58 ` Dave Chinner [this message]
2017-10-11 13:02 ` Brian Foster
2017-10-12 0:56 ` Dave Chinner
2017-10-12 10:39 ` Brian Foster
2017-10-16 19:39 ` Darrick J. Wong
2017-10-09 18:47 ` [PATCH 0/4] xfs: miscellaneous fixes Darrick J. Wong
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=20171011115858.GZ3666@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=linux-xfs@vger.kernel.org \
/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).