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
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
To: Dave Chinner <david@fromorbit.com>
Cc: Minchan Kim <minchan@kernel.org>,
Brian Foster <bfoster@redhat.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
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.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
To: Dave Chinner <david@fromorbit.com>
Cc: Minchan Kim <minchan@kernel.org>,
Brian Foster <bfoster@redhat.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
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.
>
next prev parent reply other threads:[~2016-05-31 8:03 UTC|newest]
Thread overview: 99+ 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 8:02 ` Stefan Priebe
2016-02-20 14:45 ` Brian Foster
2016-02-20 14:45 ` Brian Foster
2016-02-20 18:02 ` Stefan Priebe - Profihost AG
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 18:47 ` Stefan Priebe
2016-03-04 19:13 ` Brian Foster
2016-03-04 19:13 ` Brian Foster
2016-03-04 20:02 ` Stefan Priebe
2016-03-04 20:02 ` Stefan Priebe
2016-03-04 21:03 ` Brian Foster
2016-03-04 21:03 ` Brian Foster
2016-03-04 21:15 ` Stefan Priebe
2016-03-04 21:15 ` Stefan Priebe
2016-03-05 22:48 ` Dave Chinner
2016-03-05 22:48 ` Dave Chinner
2016-03-05 22:58 ` Stefan Priebe
2016-03-05 22:58 ` Stefan Priebe
2016-03-23 13:26 ` Stefan Priebe - Profihost AG
2016-03-23 13:26 ` Stefan Priebe - Profihost AG
2016-03-23 13:28 ` Stefan Priebe - Profihost AG
2016-03-23 13:28 ` Stefan Priebe - Profihost AG
2016-03-23 14:07 ` Brian Foster
2016-03-23 14:07 ` Brian Foster
2016-03-24 8:10 ` Stefan Priebe - Profihost AG
2016-03-24 8:10 ` Stefan Priebe - Profihost AG
2016-03-24 8:15 ` Stefan Priebe - Profihost AG
2016-03-24 8:15 ` Stefan Priebe - Profihost AG
2016-03-24 11:17 ` Brian Foster
2016-03-24 11:17 ` Brian Foster
2016-03-24 12:17 ` Stefan Priebe - Profihost AG
2016-03-24 12:17 ` Stefan Priebe - Profihost AG
2016-03-24 12:24 ` Brian Foster
2016-03-24 12:24 ` Brian Foster
2016-04-04 6:12 ` Stefan Priebe - Profihost AG
2016-04-04 6:12 ` Stefan Priebe - Profihost AG
2016-05-11 12:26 ` Stefan Priebe - Profihost AG
2016-05-11 12:26 ` Stefan Priebe - Profihost AG
2016-05-11 13:34 ` Brian Foster
2016-05-11 13:34 ` Brian Foster
2016-05-11 14:03 ` Stefan Priebe - Profihost AG
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-30 22:36 ` Dave Chinner
2016-05-30 22:36 ` Dave Chinner
2016-05-31 1:07 ` Minchan Kim
2016-05-31 1:07 ` Minchan Kim
2016-05-31 1:07 ` Minchan Kim
2016-05-31 2:55 ` Dave Chinner
2016-05-31 2:55 ` Dave Chinner
2016-05-31 2:55 ` Dave Chinner
2016-05-31 3:59 ` Minchan Kim
2016-05-31 3:59 ` Minchan Kim
2016-05-31 3:59 ` Minchan Kim
2016-05-31 6:07 ` Dave Chinner
2016-05-31 6:07 ` Dave Chinner
2016-05-31 6:07 ` Dave Chinner
2016-05-31 6:11 ` Stefan Priebe - Profihost AG
2016-05-31 6:11 ` Stefan Priebe - Profihost AG
2016-05-31 6:11 ` Stefan Priebe - Profihost AG
2016-05-31 7:31 ` Dave Chinner
2016-05-31 7:31 ` Dave Chinner
2016-05-31 7:31 ` Dave Chinner
2016-05-31 8:03 ` Stefan Priebe - Profihost AG [this message]
2016-05-31 8:03 ` Stefan Priebe - Profihost AG
2016-05-31 8:03 ` Stefan Priebe - Profihost AG
2016-06-02 12:13 ` Stefan Priebe - Profihost AG
2016-06-02 12:13 ` Stefan Priebe - Profihost AG
2016-06-02 12:13 ` Stefan Priebe - Profihost AG
2016-06-02 12:44 ` Holger Hoffstätte
2016-06-02 12:44 ` Holger Hoffstätte
2016-06-02 12:44 ` Holger Hoffstätte
2016-06-02 23:08 ` Dave Chinner
2016-06-02 23:08 ` Dave Chinner
2016-06-02 23:08 ` Dave Chinner
2016-05-31 9:50 ` Jan Kara
2016-05-31 9:50 ` Jan Kara
2016-05-31 9:50 ` Jan Kara
2016-06-01 1:38 ` Minchan Kim
2016-06-01 1:38 ` Minchan Kim
2016-06-01 1:38 ` Minchan Kim
2016-08-17 15:37 ` Andreas Grünbacher
2016-08-17 15:37 ` Andreas Grünbacher
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 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.