From: "Holger Hoffstätte" <holger@applied-asynchrony.com>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
Dave Chinner <david@fromorbit.com>
Cc: linux-mm@kvack.org, Brian Foster <bfoster@redhat.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
linux-kernel@vger.kernel.org, Minchan Kim <minchan@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: Thu, 2 Jun 2016 14:44:30 +0200 [thread overview]
Message-ID: <57502A2E.60702@applied-asynchrony.com> (raw)
In-Reply-To: <575022D2.7030502@profihost.ag>
On 06/02/16 14:13, Stefan Priebe - Profihost AG wrote:
>
> 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.
>
> Any idea what i could do with 4.4.X? Can i safely remove the WARN_ONCE
> statement?
By definition it won't break anything since it's just a heads-up message,
so yes, it should be "safe". However if my understanding of the situation
is correct, mainline commit f0281a00fe "mm: workingset: only do workingset
activations on reads" (+ friends) in 4.7 should effectively prevent this
from happenning. Can someone confirm or deny this?
-h
PS: Stefan: I backported that commit (and friends) to my 4.4.x patch queue,
so if you want to try that for today's 4.4.12 the warning should be gone.
No guarantees though :)
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: "Holger Hoffstätte" <holger@applied-asynchrony.com>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
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: Thu, 2 Jun 2016 14:44:30 +0200 [thread overview]
Message-ID: <57502A2E.60702@applied-asynchrony.com> (raw)
In-Reply-To: <575022D2.7030502@profihost.ag>
On 06/02/16 14:13, Stefan Priebe - Profihost AG wrote:
>
> 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.
>
> Any idea what i could do with 4.4.X? Can i safely remove the WARN_ONCE
> statement?
By definition it won't break anything since it's just a heads-up message,
so yes, it should be "safe". However if my understanding of the situation
is correct, mainline commit f0281a00fe "mm: workingset: only do workingset
activations on reads" (+ friends) in 4.7 should effectively prevent this
from happenning. Can someone confirm or deny this?
-h
PS: Stefan: I backported that commit (and friends) to my 4.4.x patch queue,
so if you want to try that for today's 4.4.12 the warning should be gone.
No guarantees though :)
--
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: "Holger Hoffstätte" <holger@applied-asynchrony.com>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
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: Thu, 2 Jun 2016 14:44:30 +0200 [thread overview]
Message-ID: <57502A2E.60702@applied-asynchrony.com> (raw)
In-Reply-To: <575022D2.7030502@profihost.ag>
On 06/02/16 14:13, Stefan Priebe - Profihost AG wrote:
>
> 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.
>
> Any idea what i could do with 4.4.X? Can i safely remove the WARN_ONCE
> statement?
By definition it won't break anything since it's just a heads-up message,
so yes, it should be "safe". However if my understanding of the situation
is correct, mainline commit f0281a00fe "mm: workingset: only do workingset
activations on reads" (+ friends) in 4.7 should effectively prevent this
from happenning. Can someone confirm or deny this?
-h
PS: Stefan: I backported that commit (and friends) to my 4.4.x patch queue,
so if you want to try that for today's 4.4.12 the warning should be gone.
No guarantees though :)
next prev parent reply other threads:[~2016-06-02 12:44 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
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 [this message]
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=57502A2E.60702@applied-asynchrony.com \
--to=holger@applied-asynchrony.com \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=s.priebe@profihost.ag \
--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.