From: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-mm@kvack.org, Minchan Kim <minchan@kernel.org>,
Brian Foster <bfoster@redhat.com>,
linux-kernel@vger.kernel.org, "xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: shrink_active_list/try_to_release_page bug? (was Re: xfs trace in 4.4.2 / also in 4.3.3 WARNING fs/xfs/xfs_aops.c:1232 xfs_vm_releasepage)
Date: Tue, 31 May 2016 10:03:41 +0200 [thread overview]
Message-ID: <574D455D.8050101@profihost.ag> (raw)
In-Reply-To: <20160531073119.GD12670@dastard>
Am 31.05.2016 um 09:31 schrieb Dave Chinner:
> On Tue, May 31, 2016 at 08:11:42AM +0200, Stefan Priebe - Profihost AG wrote:
>>> I'm half tempted at this point to mostly ignore this mm/ behavour
>>> because we are moving down the path of removing buffer heads from
>>> XFS. That will require us to do different things in ->releasepage
>>> and so just skipping dirty pages in the XFS code is the best thing
>>> to do....
>>
>> does this change anything i should test? Or is 4.6 still the way to go?
>
> Doesn't matter now - the warning will still be there on 4.6. I think
> you can simply ignore it as the XFS code appears to be handling the
> dirty page that is being passed to it correctly. We'll work out what
> needs to be done to get rid of the warning for this case, wether it
> be a mm/ change or an XFS change.
So is it OK to remove the WARN_ONCE in kernel code? So i don't get
alarms from our monitoring systems for the trace.
Stefan
>
> Cheers,
>
> Dave.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-05-31 8:03 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-20 8:02 xfs trace in 4.4.2 Stefan Priebe
2016-02-20 14:45 ` Brian Foster
2016-02-20 18:02 ` Stefan Priebe - Profihost AG
2016-03-04 18:47 ` xfs trace in 4.4.2 / also in 4.3.3 WARNING fs/xfs/xfs_aops.c:1232 xfs_vm_releasepage Stefan Priebe
2016-03-04 19:13 ` Brian Foster
2016-03-04 20:02 ` Stefan Priebe
2016-03-04 21:03 ` Brian Foster
2016-03-04 21:15 ` Stefan Priebe
2016-03-05 22:48 ` Dave Chinner
2016-03-05 22:58 ` Stefan Priebe
2016-03-23 13:26 ` Stefan Priebe - Profihost AG
2016-03-23 13:28 ` Stefan Priebe - Profihost AG
2016-03-23 14:07 ` Brian Foster
2016-03-24 8:10 ` Stefan Priebe - Profihost AG
2016-03-24 8:15 ` Stefan Priebe - Profihost AG
2016-03-24 11:17 ` Brian Foster
2016-03-24 12:17 ` Stefan Priebe - Profihost AG
2016-03-24 12:24 ` Brian Foster
2016-04-04 6:12 ` Stefan Priebe - Profihost AG
2016-05-11 12:26 ` Stefan Priebe - Profihost AG
2016-05-11 13:34 ` Brian Foster
2016-05-11 14:03 ` Stefan Priebe - Profihost AG
2016-05-11 15:59 ` Brian Foster
2016-05-11 19:20 ` Stefan Priebe
2016-05-15 11:03 ` Stefan Priebe
2016-05-15 11:50 ` Brian Foster
2016-05-15 12:41 ` Stefan Priebe
2016-05-16 1:06 ` Brian Foster
2016-05-22 19:36 ` Stefan Priebe - Profihost AG
2016-05-22 21:38 ` Dave Chinner
2016-05-30 7:23 ` Stefan Priebe - Profihost AG
2016-05-30 22:36 ` shrink_active_list/try_to_release_page bug? (was Re: xfs trace in 4.4.2 / also in 4.3.3 WARNING fs/xfs/xfs_aops.c:1232 xfs_vm_releasepage) Dave Chinner
2016-05-31 1:07 ` Minchan Kim
2016-05-31 2:55 ` Dave Chinner
2016-05-31 3:59 ` Minchan Kim
2016-05-31 6:07 ` Dave Chinner
2016-05-31 6:11 ` Stefan Priebe - Profihost AG
2016-05-31 7:31 ` Dave Chinner
2016-05-31 8:03 ` Stefan Priebe - Profihost AG [this message]
2016-06-02 12:13 ` Stefan Priebe - Profihost AG
2016-06-02 12:44 ` Holger Hoffstätte
2016-06-02 23:08 ` Dave Chinner
2016-05-31 9:50 ` Jan Kara
2016-06-01 1:38 ` Minchan Kim
2016-08-17 15:37 ` Andreas Grünbacher
2016-06-03 17:56 ` xfs trace in 4.4.2 / also in 4.3.3 WARNING fs/xfs/xfs_aops.c:1232 xfs_vm_releasepage Stefan Priebe - Profihost AG
2016-06-03 19:35 ` Holger Hoffstätte
2016-06-04 0:04 ` Dave Chinner
2016-06-26 5:45 ` Stefan Priebe
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=574D455D.8050101@profihost.ag \
--to=s.priebe@profihost.ag \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=xfs@oss.sgi.com \
/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