* Re: migratepage failures on reiserfs
@ 2007-10-30 22:58 ` Chris Mason
0 siblings, 0 replies; 35+ messages in thread
From: Chris Mason @ 2007-10-30 22:58 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Tue, 30 Oct 2007 13:54:05 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
> > On Tue, 30 Oct 2007 10:27:04 -0800
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > > Hi,
> > >
> > > While testing hotplug memory remove, I ran into this issue. Given
> > > a range of pages hotplug memory remove tries to migrate those
> > > pages.
> > >
> > > migrate_pages() keeps failing to migrate pages containing
> > > pagecache pages for reiserfs files. I noticed that reiserfs
> > > doesn't have ->migratepage() ops. So, fallback_migrate_page()
> > > code tries to do try_to_release_page(). try_to_release_page()
> > > fails to drop_buffers() since b_count == 1. Here is what my debug
> > > shows:
> > >
> > > migrate pages failed pfn 258111/flags 3f00000000801
> > > bh c00000000b53f6e0 flags 110029 count 1
> > >
> > > Any one know why the b_count == 1 and not getting dropped to
> > > zero ?
> >
> > If these are file data pages, the count is probably elevated as
> > part of the data=ordered tracking. You can verify this via
> > b_private, or just mount data=writeback to double check.
>
>
> Chris,
>
> That was my first assumption. But after looking at
> reiserfs_releasepage (), realized that it would do reiserfs_free_jh()
> and clears the b_private. I couldn't easily find out who has the ref.
> against this bh.
>
> bh c00000000bdaaf00 flags 110029 count 1 private 0
>
If I'm reading this correctly the buffer is BH_Lock | BH_Req, perhaps
it is currently under IO?
The page isn't locked, but data=ordered does IO directly on the buffer
heads, without taking the page lock.
The easy way to narrow our search is to try without data=ordered, it is
certainly complicating things.
-chris
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-10-30 22:58 ` Chris Mason
@ 2007-10-30 23:08 ` Badari
-1 siblings, 0 replies; 35+ messages in thread
From: Badari @ 2007-10-30 23:08 UTC (permalink / raw)
To: Chris Mason; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
Chris Mason wrote:
> On Tue, 30 Oct 2007 13:54:05 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
>
>> On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
>>
>>> On Tue, 30 Oct 2007 10:27:04 -0800
>>> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> While testing hotplug memory remove, I ran into this issue. Given
>>>> a range of pages hotplug memory remove tries to migrate those
>>>> pages.
>>>>
>>>> migrate_pages() keeps failing to migrate pages containing
>>>> pagecache pages for reiserfs files. I noticed that reiserfs
>>>> doesn't have ->migratepage() ops. So, fallback_migrate_page()
>>>> code tries to do try_to_release_page(). try_to_release_page()
>>>> fails to drop_buffers() since b_count == 1. Here is what my debug
>>>> shows:
>>>>
>>>> migrate pages failed pfn 258111/flags 3f00000000801
>>>> bh c00000000b53f6e0 flags 110029 count 1
>>>>
>>>> Any one know why the b_count == 1 and not getting dropped to
>>>> zero ?
>>>>
>>> If these are file data pages, the count is probably elevated as
>>> part of the data=ordered tracking. You can verify this via
>>> b_private, or just mount data=writeback to double check.
>>>
>> Chris,
>>
>> That was my first assumption. But after looking at
>> reiserfs_releasepage (), realized that it would do reiserfs_free_jh()
>> and clears the b_private. I couldn't easily find out who has the ref.
>> against this bh.
>>
>> bh c00000000bdaaf00 flags 110029 count 1 private 0
>>
>>
>
> If I'm reading this correctly the buffer is BH_Lock | BH_Req, perhaps
> it is currently under IO?
>
Its BH_Req | BH_Uptodate. Its not under IO.
> The page isn't locked, but data=ordered does IO directly on the buffer
> heads, without taking the page lock.
>
> The easy way to narrow our search is to try without data=ordered, it is
> certainly complicating things.
>
I can try that, its my root filesystem :(
Thanks,
Badari
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-10-30 23:08 ` Badari
0 siblings, 0 replies; 35+ messages in thread
From: Badari @ 2007-10-30 23:08 UTC (permalink / raw)
To: Chris Mason; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
Chris Mason wrote:
> On Tue, 30 Oct 2007 13:54:05 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
>
>> On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
>>
>>> On Tue, 30 Oct 2007 10:27:04 -0800
>>> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> While testing hotplug memory remove, I ran into this issue. Given
>>>> a range of pages hotplug memory remove tries to migrate those
>>>> pages.
>>>>
>>>> migrate_pages() keeps failing to migrate pages containing
>>>> pagecache pages for reiserfs files. I noticed that reiserfs
>>>> doesn't have ->migratepage() ops. So, fallback_migrate_page()
>>>> code tries to do try_to_release_page(). try_to_release_page()
>>>> fails to drop_buffers() since b_count == 1. Here is what my debug
>>>> shows:
>>>>
>>>> migrate pages failed pfn 258111/flags 3f00000000801
>>>> bh c00000000b53f6e0 flags 110029 count 1
>>>>
>>>> Any one know why the b_count == 1 and not getting dropped to
>>>> zero ?
>>>>
>>> If these are file data pages, the count is probably elevated as
>>> part of the data=ordered tracking. You can verify this via
>>> b_private, or just mount data=writeback to double check.
>>>
>> Chris,
>>
>> That was my first assumption. But after looking at
>> reiserfs_releasepage (), realized that it would do reiserfs_free_jh()
>> and clears the b_private. I couldn't easily find out who has the ref.
>> against this bh.
>>
>> bh c00000000bdaaf00 flags 110029 count 1 private 0
>>
>>
>
> If I'm reading this correctly the buffer is BH_Lock | BH_Req, perhaps
> it is currently under IO?
>
Its BH_Req | BH_Uptodate. Its not under IO.
> The page isn't locked, but data=ordered does IO directly on the buffer
> heads, without taking the page lock.
>
> The easy way to narrow our search is to try without data=ordered, it is
> certainly complicating things.
>
I can try that, its my root filesystem :(
Thanks,
Badari
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-10-30 23:08 ` Badari
(?)
@ 2007-10-31 0:05 ` Zan Lynx
-1 siblings, 0 replies; 35+ messages in thread
From: Zan Lynx @ 2007-10-31 0:05 UTC (permalink / raw)
To: Badari; +Cc: Chris Mason, reiserfs-devel, linux-mm, linux-fsdevel
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]
On Tue, 2007-10-30 at 16:08 -0700, Badari wrote:
> Chris Mason wrote:
> > On Tue, 30 Oct 2007 13:54:05 -0800
[cut]
> > The easy way to narrow our search is to try without data=ordered, it is
> > certainly complicating things.
> >
>
> I can try that, its my root filesystem :(
You meant to write "can't?"
Download BusyBox and build it into an initramfs. It's pretty easy, you
can do it yourself. Or you could download the Debian mkinitramfs (I
think) package and look at it. Or the Fedora equivalent (I think
mkinitrd).
Then you can boot into that and mount your / with whatever options you
like.
Here's what I use for my own custom BusyBox initramfs /init script:
#!/bin/sh
get_arg() {
local arg="$1"
local x=`cat /proc/cmdline`
for i in $x; do
if [ "${i%=*}" = "$arg" ]; then
echo ${i#*=}
break
fi
done
}
do_switch() {
mount -t proc none /proc
local root=`get_arg root`
local flags=`get_arg rootflags`
mount "$root" /new ${flags:+-o "$flags"}
umount /proc
cd /new
exec switch_root . /sbin/init
}
do_shell() {
exec /sbin/init
}
# The following will wait 2 seconds for Enter before booting.
trap "do_switch" ALRM
target=$$
( sleep 2; kill -ALRM $target ) &
alarm=$!
echo -n "Press Enter for a shell: "
while read action; do
kill $alarm
break
done
do_shell
--
Zan Lynx <zlynx@acm.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-10-30 22:58 ` Chris Mason
@ 2007-10-31 16:14 ` Badari Pulavarty
-1 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-10-31 16:14 UTC (permalink / raw)
To: Chris Mason; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Tue, 2007-10-30 at 18:58 -0400, Chris Mason wrote:
> On Tue, 30 Oct 2007 13:54:05 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
> > > On Tue, 30 Oct 2007 10:27:04 -0800
> > > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > While testing hotplug memory remove, I ran into this issue. Given
> > > > a range of pages hotplug memory remove tries to migrate those
> > > > pages.
> > > >
> > > > migrate_pages() keeps failing to migrate pages containing
> > > > pagecache pages for reiserfs files. I noticed that reiserfs
> > > > doesn't have ->migratepage() ops. So, fallback_migrate_page()
> > > > code tries to do try_to_release_page(). try_to_release_page()
> > > > fails to drop_buffers() since b_count == 1. Here is what my debug
> > > > shows:
> > > >
> > > > migrate pages failed pfn 258111/flags 3f00000000801
> > > > bh c00000000b53f6e0 flags 110029 count 1
> > > >
> > > > Any one know why the b_count == 1 and not getting dropped to
> > > > zero ?
> > >
> > > If these are file data pages, the count is probably elevated as
> > > part of the data=ordered tracking. You can verify this via
> > > b_private, or just mount data=writeback to double check.
> >
> >
> > Chris,
> >
> > That was my first assumption. But after looking at
> > reiserfs_releasepage (), realized that it would do reiserfs_free_jh()
> > and clears the b_private. I couldn't easily find out who has the ref.
> > against this bh.
> >
> > bh c00000000bdaaf00 flags 110029 count 1 private 0
> >
>
> If I'm reading this correctly the buffer is BH_Lock | BH_Req, perhaps
> it is currently under IO?
>
> The page isn't locked, but data=ordered does IO directly on the buffer
> heads, without taking the page lock.
>
> The easy way to narrow our search is to try without data=ordered, it is
> certainly complicating things.
I tried data=writeback mode and it didn't help :(
unable to release the page 262070
bh c0000000211b9408 flags 110029 count 1 private 0
unable to release the page 262098
bh c000000020ec9198 flags 110029 count 1 private 0
memory offlining 3f000 to 40000 failed
# cat /etc/mtab
/dev/sda3 / reiserfs rw,data=writeback 0 0
proc /proc proc rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw,mode=0620,gid=5 0 0
Thanks,
Badari
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-10-31 16:14 ` Badari Pulavarty
0 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-10-31 16:14 UTC (permalink / raw)
To: Chris Mason; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Tue, 2007-10-30 at 18:58 -0400, Chris Mason wrote:
> On Tue, 30 Oct 2007 13:54:05 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
> > > On Tue, 30 Oct 2007 10:27:04 -0800
> > > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > While testing hotplug memory remove, I ran into this issue. Given
> > > > a range of pages hotplug memory remove tries to migrate those
> > > > pages.
> > > >
> > > > migrate_pages() keeps failing to migrate pages containing
> > > > pagecache pages for reiserfs files. I noticed that reiserfs
> > > > doesn't have ->migratepage() ops. So, fallback_migrate_page()
> > > > code tries to do try_to_release_page(). try_to_release_page()
> > > > fails to drop_buffers() since b_count == 1. Here is what my debug
> > > > shows:
> > > >
> > > > migrate pages failed pfn 258111/flags 3f00000000801
> > > > bh c00000000b53f6e0 flags 110029 count 1
> > > >
> > > > Any one know why the b_count == 1 and not getting dropped to
> > > > zero ?
> > >
> > > If these are file data pages, the count is probably elevated as
> > > part of the data=ordered tracking. You can verify this via
> > > b_private, or just mount data=writeback to double check.
> >
> >
> > Chris,
> >
> > That was my first assumption. But after looking at
> > reiserfs_releasepage (), realized that it would do reiserfs_free_jh()
> > and clears the b_private. I couldn't easily find out who has the ref.
> > against this bh.
> >
> > bh c00000000bdaaf00 flags 110029 count 1 private 0
> >
>
> If I'm reading this correctly the buffer is BH_Lock | BH_Req, perhaps
> it is currently under IO?
>
> The page isn't locked, but data=ordered does IO directly on the buffer
> heads, without taking the page lock.
>
> The easy way to narrow our search is to try without data=ordered, it is
> certainly complicating things.
I tried data=writeback mode and it didn't help :(
unable to release the page 262070
bh c0000000211b9408 flags 110029 count 1 private 0
unable to release the page 262098
bh c000000020ec9198 flags 110029 count 1 private 0
memory offlining 3f000 to 40000 failed
# cat /etc/mtab
/dev/sda3 / reiserfs rw,data=writeback 0 0
proc /proc proc rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw,mode=0620,gid=5 0 0
Thanks,
Badari
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-10-31 16:14 ` Badari Pulavarty
@ 2007-10-31 17:40 ` Chris Mason
-1 siblings, 0 replies; 35+ messages in thread
From: Chris Mason @ 2007-10-31 17:40 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Wed, 31 Oct 2007 08:14:21 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> I tried data=writeback mode and it didn't help :(
Ouch, so much for the easy way out.
>
> unable to release the page 262070
> bh c0000000211b9408 flags 110029 count 1 private 0
> unable to release the page 262098
> bh c000000020ec9198 flags 110029 count 1 private 0
> memory offlining 3f000 to 40000 failed
>
The only other special thing reiserfs does with the page cache is file
tails. I don't suppose all of these pages are index zero in files
smaller than 4k?
-chris
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-10-31 17:40 ` Chris Mason
0 siblings, 0 replies; 35+ messages in thread
From: Chris Mason @ 2007-10-31 17:40 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Wed, 31 Oct 2007 08:14:21 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> I tried data=writeback mode and it didn't help :(
Ouch, so much for the easy way out.
>
> unable to release the page 262070
> bh c0000000211b9408 flags 110029 count 1 private 0
> unable to release the page 262098
> bh c000000020ec9198 flags 110029 count 1 private 0
> memory offlining 3f000 to 40000 failed
>
The only other special thing reiserfs does with the page cache is file
tails. I don't suppose all of these pages are index zero in files
smaller than 4k?
-chris
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-10-31 17:40 ` Chris Mason
@ 2007-11-01 16:38 ` Badari Pulavarty
-1 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-01 16:38 UTC (permalink / raw)
To: Chris Mason; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> On Wed, 31 Oct 2007 08:14:21 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > I tried data=writeback mode and it didn't help :(
>
> Ouch, so much for the easy way out.
>
> >
> > unable to release the page 262070
> > bh c0000000211b9408 flags 110029 count 1 private 0
> > unable to release the page 262098
> > bh c000000020ec9198 flags 110029 count 1 private 0
> > memory offlining 3f000 to 40000 failed
> >
>
> The only other special thing reiserfs does with the page cache is file
> tails. I don't suppose all of these pages are index zero in files
> smaller than 4k?
Ahhhhhhhhhhhhh !! I am so blind :(
I have been suspecting reiserfs all along, since its executing
fallback_migrate_page(). Actually, these buffer heads are
backing blockdev. I guess these are metadata buffers :(
I am not sure we can do much with these..
Thanks,
Badari
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-01 16:38 ` Badari Pulavarty
0 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-01 16:38 UTC (permalink / raw)
To: Chris Mason; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> On Wed, 31 Oct 2007 08:14:21 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > I tried data=writeback mode and it didn't help :(
>
> Ouch, so much for the easy way out.
>
> >
> > unable to release the page 262070
> > bh c0000000211b9408 flags 110029 count 1 private 0
> > unable to release the page 262098
> > bh c000000020ec9198 flags 110029 count 1 private 0
> > memory offlining 3f000 to 40000 failed
> >
>
> The only other special thing reiserfs does with the page cache is file
> tails. I don't suppose all of these pages are index zero in files
> smaller than 4k?
Ahhhhhhhhhhhhh !! I am so blind :(
I have been suspecting reiserfs all along, since its executing
fallback_migrate_page(). Actually, these buffer heads are
backing blockdev. I guess these are metadata buffers :(
I am not sure we can do much with these..
Thanks,
Badari
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-11-01 16:38 ` Badari Pulavarty
@ 2007-11-01 15:51 ` Chris Mason
-1 siblings, 0 replies; 35+ messages in thread
From: Chris Mason @ 2007-11-01 15:51 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Thu, 01 Nov 2007 08:38:57 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> > On Wed, 31 Oct 2007 08:14:21 -0800
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > >
> > > I tried data=writeback mode and it didn't help :(
> >
> > Ouch, so much for the easy way out.
> >
> > >
> > > unable to release the page 262070
> > > bh c0000000211b9408 flags 110029 count 1 private 0
> > > unable to release the page 262098
> > > bh c000000020ec9198 flags 110029 count 1 private 0
> > > memory offlining 3f000 to 40000 failed
> > >
> >
> > The only other special thing reiserfs does with the page cache is
> > file tails. I don't suppose all of these pages are index zero in
> > files smaller than 4k?
>
> Ahhhhhhhhhhhhh !! I am so blind :(
>
> I have been suspecting reiserfs all along, since its executing
> fallback_migrate_page(). Actually, these buffer heads are
> backing blockdev. I guess these are metadata buffers :(
> I am not sure we can do much with these..
Hmpf, my first reply had a paragraph about the block device inode
pages, I noticed the phrase file data pages and deleted it ;)
But, for the metadata buffers there's not much we can do. They are
included in a bunch of different lists and the patch would
be non-trivial.
-chris
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-01 15:51 ` Chris Mason
0 siblings, 0 replies; 35+ messages in thread
From: Chris Mason @ 2007-11-01 15:51 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Thu, 01 Nov 2007 08:38:57 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> > On Wed, 31 Oct 2007 08:14:21 -0800
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > >
> > > I tried data=writeback mode and it didn't help :(
> >
> > Ouch, so much for the easy way out.
> >
> > >
> > > unable to release the page 262070
> > > bh c0000000211b9408 flags 110029 count 1 private 0
> > > unable to release the page 262098
> > > bh c000000020ec9198 flags 110029 count 1 private 0
> > > memory offlining 3f000 to 40000 failed
> > >
> >
> > The only other special thing reiserfs does with the page cache is
> > file tails. I don't suppose all of these pages are index zero in
> > files smaller than 4k?
>
> Ahhhhhhhhhhhhh !! I am so blind :(
>
> I have been suspecting reiserfs all along, since its executing
> fallback_migrate_page(). Actually, these buffer heads are
> backing blockdev. I guess these are metadata buffers :(
> I am not sure we can do much with these..
Hmpf, my first reply had a paragraph about the block device inode
pages, I noticed the phrase file data pages and deleted it ;)
But, for the metadata buffers there's not much we can do. They are
included in a bunch of different lists and the patch would
be non-trivial.
-chris
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-11-01 15:51 ` Chris Mason
@ 2007-11-01 18:10 ` Badari Pulavarty
-1 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-01 18:10 UTC (permalink / raw)
To: Chris Mason, mel; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Thu, 2007-11-01 at 11:51 -0400, Chris Mason wrote:
> On Thu, 01 Nov 2007 08:38:57 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> > > On Wed, 31 Oct 2007 08:14:21 -0800
> > > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > >
> > > > I tried data=writeback mode and it didn't help :(
> > >
> > > Ouch, so much for the easy way out.
> > >
> > > >
> > > > unable to release the page 262070
> > > > bh c0000000211b9408 flags 110029 count 1 private 0
> > > > unable to release the page 262098
> > > > bh c000000020ec9198 flags 110029 count 1 private 0
> > > > memory offlining 3f000 to 40000 failed
> > > >
> > >
> > > The only other special thing reiserfs does with the page cache is
> > > file tails. I don't suppose all of these pages are index zero in
> > > files smaller than 4k?
> >
> > Ahhhhhhhhhhhhh !! I am so blind :(
> >
> > I have been suspecting reiserfs all along, since its executing
> > fallback_migrate_page(). Actually, these buffer heads are
> > backing blockdev. I guess these are metadata buffers :(
> > I am not sure we can do much with these..
>
> Hmpf, my first reply had a paragraph about the block device inode
> pages, I noticed the phrase file data pages and deleted it ;)
>
> But, for the metadata buffers there's not much we can do. They are
> included in a bunch of different lists and the patch would
> be non-trivial.
Unfortunately, these buffer pages are spread all around making
those sections of memory non-removable. Of course, one can use
ZONE_MOVABLE to make sure to guarantee the remove. But I am
hoping we could easily group all these allocations and minimize
spreading them around. Mel ?
Thanks,
Badari
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-01 18:10 ` Badari Pulavarty
0 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-01 18:10 UTC (permalink / raw)
To: Chris Mason, mel; +Cc: reiserfs-devel, linux-mm, linux-fsdevel
On Thu, 2007-11-01 at 11:51 -0400, Chris Mason wrote:
> On Thu, 01 Nov 2007 08:38:57 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> > > On Wed, 31 Oct 2007 08:14:21 -0800
> > > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > >
> > > > I tried data=writeback mode and it didn't help :(
> > >
> > > Ouch, so much for the easy way out.
> > >
> > > >
> > > > unable to release the page 262070
> > > > bh c0000000211b9408 flags 110029 count 1 private 0
> > > > unable to release the page 262098
> > > > bh c000000020ec9198 flags 110029 count 1 private 0
> > > > memory offlining 3f000 to 40000 failed
> > > >
> > >
> > > The only other special thing reiserfs does with the page cache is
> > > file tails. I don't suppose all of these pages are index zero in
> > > files smaller than 4k?
> >
> > Ahhhhhhhhhhhhh !! I am so blind :(
> >
> > I have been suspecting reiserfs all along, since its executing
> > fallback_migrate_page(). Actually, these buffer heads are
> > backing blockdev. I guess these are metadata buffers :(
> > I am not sure we can do much with these..
>
> Hmpf, my first reply had a paragraph about the block device inode
> pages, I noticed the phrase file data pages and deleted it ;)
>
> But, for the metadata buffers there's not much we can do. They are
> included in a bunch of different lists and the patch would
> be non-trivial.
Unfortunately, these buffer pages are spread all around making
those sections of memory non-removable. Of course, one can use
ZONE_MOVABLE to make sure to guarantee the remove. But I am
hoping we could easily group all these allocations and minimize
spreading them around. Mel ?
Thanks,
Badari
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-11-01 18:10 ` Badari Pulavarty
@ 2007-11-02 16:46 ` Badari Pulavarty
-1 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-02 16:46 UTC (permalink / raw)
To: Chris Mason; +Cc: mel, reiserfs-devel, linux-mm, linux-fsdevel
On Thu, 2007-11-01 at 10:10 -0800, Badari Pulavarty wrote:
> On Thu, 2007-11-01 at 11:51 -0400, Chris Mason wrote:
> > On Thu, 01 Nov 2007 08:38:57 -0800
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > > On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> > > > On Wed, 31 Oct 2007 08:14:21 -0800
> > > > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > > >
> > > > > I tried data=writeback mode and it didn't help :(
> > > >
> > > > Ouch, so much for the easy way out.
> > > >
> > > > >
> > > > > unable to release the page 262070
> > > > > bh c0000000211b9408 flags 110029 count 1 private 0
> > > > > unable to release the page 262098
> > > > > bh c000000020ec9198 flags 110029 count 1 private 0
> > > > > memory offlining 3f000 to 40000 failed
> > > > >
> > > >
> > > > The only other special thing reiserfs does with the page cache is
> > > > file tails. I don't suppose all of these pages are index zero in
> > > > files smaller than 4k?
> > >
> > > Ahhhhhhhhhhhhh !! I am so blind :(
> > >
> > > I have been suspecting reiserfs all along, since its executing
> > > fallback_migrate_page(). Actually, these buffer heads are
> > > backing blockdev. I guess these are metadata buffers :(
> > > I am not sure we can do much with these..
> >
> > Hmpf, my first reply had a paragraph about the block device inode
> > pages, I noticed the phrase file data pages and deleted it ;)
> >
> > But, for the metadata buffers there's not much we can do. They are
> > included in a bunch of different lists and the patch would
> > be non-trivial.
>
> Unfortunately, these buffer pages are spread all around making
> those sections of memory non-removable. Of course, one can use
> ZONE_MOVABLE to make sure to guarantee the remove. But I am
> hoping we could easily group all these allocations and minimize
> spreading them around. Mel ?
>
BTW, I am having better luck with being able to offline sections
of memory on x86-64, if I take out __GFP_MOVABLE flag for
blockdev pages. (in grow_dev_page()).
Thanks,
Badari
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-02 16:46 ` Badari Pulavarty
0 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-02 16:46 UTC (permalink / raw)
To: Chris Mason; +Cc: mel, reiserfs-devel, linux-mm, linux-fsdevel
On Thu, 2007-11-01 at 10:10 -0800, Badari Pulavarty wrote:
> On Thu, 2007-11-01 at 11:51 -0400, Chris Mason wrote:
> > On Thu, 01 Nov 2007 08:38:57 -0800
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > > On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> > > > On Wed, 31 Oct 2007 08:14:21 -0800
> > > > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > > >
> > > > > I tried data=writeback mode and it didn't help :(
> > > >
> > > > Ouch, so much for the easy way out.
> > > >
> > > > >
> > > > > unable to release the page 262070
> > > > > bh c0000000211b9408 flags 110029 count 1 private 0
> > > > > unable to release the page 262098
> > > > > bh c000000020ec9198 flags 110029 count 1 private 0
> > > > > memory offlining 3f000 to 40000 failed
> > > > >
> > > >
> > > > The only other special thing reiserfs does with the page cache is
> > > > file tails. I don't suppose all of these pages are index zero in
> > > > files smaller than 4k?
> > >
> > > Ahhhhhhhhhhhhh !! I am so blind :(
> > >
> > > I have been suspecting reiserfs all along, since its executing
> > > fallback_migrate_page(). Actually, these buffer heads are
> > > backing blockdev. I guess these are metadata buffers :(
> > > I am not sure we can do much with these..
> >
> > Hmpf, my first reply had a paragraph about the block device inode
> > pages, I noticed the phrase file data pages and deleted it ;)
> >
> > But, for the metadata buffers there's not much we can do. They are
> > included in a bunch of different lists and the patch would
> > be non-trivial.
>
> Unfortunately, these buffer pages are spread all around making
> those sections of memory non-removable. Of course, one can use
> ZONE_MOVABLE to make sure to guarantee the remove. But I am
> hoping we could easily group all these allocations and minimize
> spreading them around. Mel ?
>
BTW, I am having better luck with being able to offline sections
of memory on x86-64, if I take out __GFP_MOVABLE flag for
blockdev pages. (in grow_dev_page()).
Thanks,
Badari
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-11-01 18:10 ` Badari Pulavarty
@ 2007-11-05 10:23 ` Mel Gorman
-1 siblings, 0 replies; 35+ messages in thread
From: Mel Gorman @ 2007-11-05 10:23 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Chris Mason, reiserfs-devel, linux-mm, linux-fsdevel
On (01/11/07 10:10), Badari Pulavarty didst pronounce:
> On Thu, 2007-11-01 at 11:51 -0400, Chris Mason wrote:
> > On Thu, 01 Nov 2007 08:38:57 -0800
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > > On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> > > > On Wed, 31 Oct 2007 08:14:21 -0800
> > > > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > > >
> > > > > I tried data=writeback mode and it didn't help :(
> > > >
> > > > Ouch, so much for the easy way out.
> > > >
> > > > >
> > > > > unable to release the page 262070
> > > > > bh c0000000211b9408 flags 110029 count 1 private 0
> > > > > unable to release the page 262098
> > > > > bh c000000020ec9198 flags 110029 count 1 private 0
> > > > > memory offlining 3f000 to 40000 failed
> > > > >
> > > >
> > > > The only other special thing reiserfs does with the page cache is
> > > > file tails. I don't suppose all of these pages are index zero in
> > > > files smaller than 4k?
> > >
> > > Ahhhhhhhhhhhhh !! I am so blind :(
> > >
> > > I have been suspecting reiserfs all along, since its executing
> > > fallback_migrate_page(). Actually, these buffer heads are
> > > backing blockdev. I guess these are metadata buffers :(
> > > I am not sure we can do much with these..
> >
> > Hmpf, my first reply had a paragraph about the block device inode
> > pages, I noticed the phrase file data pages and deleted it ;)
> >
> > But, for the metadata buffers there's not much we can do. They are
> > included in a bunch of different lists and the patch would
> > be non-trivial.
>
> Unfortunately, these buffer pages are spread all around making
> those sections of memory non-removable. Of course, one can use
> ZONE_MOVABLE to make sure to guarantee the remove. But I am
> hoping we could easily group all these allocations and minimize
> spreading them around. Mel ?
The grow_dev_page() pages should be reclaimable even though migration
is not supported for those pages? They were marked movable as it was
useful for lumpy reclaim taking back pages for hugepage allocations and
the like. Would it make sense for memory unremove to attempt migration
first and reclaim second?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-05 10:23 ` Mel Gorman
0 siblings, 0 replies; 35+ messages in thread
From: Mel Gorman @ 2007-11-05 10:23 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Chris Mason, reiserfs-devel, linux-mm, linux-fsdevel
On (01/11/07 10:10), Badari Pulavarty didst pronounce:
> On Thu, 2007-11-01 at 11:51 -0400, Chris Mason wrote:
> > On Thu, 01 Nov 2007 08:38:57 -0800
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > > On Wed, 2007-10-31 at 13:40 -0400, Chris Mason wrote:
> > > > On Wed, 31 Oct 2007 08:14:21 -0800
> > > > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > > >
> > > > > I tried data=writeback mode and it didn't help :(
> > > >
> > > > Ouch, so much for the easy way out.
> > > >
> > > > >
> > > > > unable to release the page 262070
> > > > > bh c0000000211b9408 flags 110029 count 1 private 0
> > > > > unable to release the page 262098
> > > > > bh c000000020ec9198 flags 110029 count 1 private 0
> > > > > memory offlining 3f000 to 40000 failed
> > > > >
> > > >
> > > > The only other special thing reiserfs does with the page cache is
> > > > file tails. I don't suppose all of these pages are index zero in
> > > > files smaller than 4k?
> > >
> > > Ahhhhhhhhhhhhh !! I am so blind :(
> > >
> > > I have been suspecting reiserfs all along, since its executing
> > > fallback_migrate_page(). Actually, these buffer heads are
> > > backing blockdev. I guess these are metadata buffers :(
> > > I am not sure we can do much with these..
> >
> > Hmpf, my first reply had a paragraph about the block device inode
> > pages, I noticed the phrase file data pages and deleted it ;)
> >
> > But, for the metadata buffers there's not much we can do. They are
> > included in a bunch of different lists and the patch would
> > be non-trivial.
>
> Unfortunately, these buffer pages are spread all around making
> those sections of memory non-removable. Of course, one can use
> ZONE_MOVABLE to make sure to guarantee the remove. But I am
> hoping we could easily group all these allocations and minimize
> spreading them around. Mel ?
The grow_dev_page() pages should be reclaimable even though migration
is not supported for those pages? They were marked movable as it was
useful for lumpy reclaim taking back pages for hugepage allocations and
the like. Would it make sense for memory unremove to attempt migration
first and reclaim second?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-11-05 10:23 ` Mel Gorman
(?)
@ 2007-11-05 13:40 ` Chris Mason
-1 siblings, 0 replies; 35+ messages in thread
From: Chris Mason @ 2007-11-05 13:40 UTC (permalink / raw)
To: Mel Gorman; +Cc: Badari Pulavarty, reiserfs-devel, linux-mm, linux-fsdevel
On Mon, 5 Nov 2007 10:23:35 +0000
mel@skynet.ie (Mel Gorman) wrote:
> On (01/11/07 10:10), Badari Pulavarty didst pronounce:
>
> > > Hmpf, my first reply had a paragraph about the block device inode
> > > pages, I noticed the phrase file data pages and deleted it ;)
> > >
> > > But, for the metadata buffers there's not much we can do. They
> > > are included in a bunch of different lists and the patch would
> > > be non-trivial.
> >
> > Unfortunately, these buffer pages are spread all around making
> > those sections of memory non-removable. Of course, one can use
> > ZONE_MOVABLE to make sure to guarantee the remove. But I am
> > hoping we could easily group all these allocations and minimize
> > spreading them around. Mel ?
>
> The grow_dev_page() pages should be reclaimable even though migration
> is not supported for those pages? They were marked movable as it was
> useful for lumpy reclaim taking back pages for hugepage allocations
> and the like. Would it make sense for memory unremove to attempt
> migration first and reclaim second?
>
In this case, reiserfs has the page pinned while it is doing journal
magic. Not sure if ext3 has the same issues.
-chris
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-05 13:40 ` Chris Mason
0 siblings, 0 replies; 35+ messages in thread
From: Chris Mason @ 2007-11-05 13:40 UTC (permalink / raw)
To: Mel Gorman; +Cc: Badari Pulavarty, reiserfs-devel, linux-mm, linux-fsdevel
On Mon, 5 Nov 2007 10:23:35 +0000
mel@skynet.ie (Mel Gorman) wrote:
> On (01/11/07 10:10), Badari Pulavarty didst pronounce:
>
> > > Hmpf, my first reply had a paragraph about the block device inode
> > > pages, I noticed the phrase file data pages and deleted it ;)
> > >
> > > But, for the metadata buffers there's not much we can do. They
> > > are included in a bunch of different lists and the patch would
> > > be non-trivial.
> >
> > Unfortunately, these buffer pages are spread all around making
> > those sections of memory non-removable. Of course, one can use
> > ZONE_MOVABLE to make sure to guarantee the remove. But I am
> > hoping we could easily group all these allocations and minimize
> > spreading them around. Mel ?
>
> The grow_dev_page() pages should be reclaimable even though migration
> is not supported for those pages? They were marked movable as it was
> useful for lumpy reclaim taking back pages for hugepage allocations
> and the like. Would it make sense for memory unremove to attempt
> migration first and reclaim second?
>
In this case, reiserfs has the page pinned while it is doing journal
magic. Not sure if ext3 has the same issues.
-chris
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-05 13:40 ` Chris Mason
0 siblings, 0 replies; 35+ messages in thread
From: Chris Mason @ 2007-11-05 13:40 UTC (permalink / raw)
To: Mel Gorman; +Cc: Badari Pulavarty, reiserfs-devel, linux-mm, linux-fsdevel
On Mon, 5 Nov 2007 10:23:35 +0000
mel@skynet.ie (Mel Gorman) wrote:
> On (01/11/07 10:10), Badari Pulavarty didst pronounce:
>
> > > Hmpf, my first reply had a paragraph about the block device inode
> > > pages, I noticed the phrase file data pages and deleted it ;)
> > >
> > > But, for the metadata buffers there's not much we can do. They
> > > are included in a bunch of different lists and the patch would
> > > be non-trivial.
> >
> > Unfortunately, these buffer pages are spread all around making
> > those sections of memory non-removable. Of course, one can use
> > ZONE_MOVABLE to make sure to guarantee the remove. But I am
> > hoping we could easily group all these allocations and minimize
> > spreading them around. Mel ?
>
> The grow_dev_page() pages should be reclaimable even though migration
> is not supported for those pages? They were marked movable as it was
> useful for lumpy reclaim taking back pages for hugepage allocations
> and the like. Would it make sense for memory unremove to attempt
> migration first and reclaim second?
>
In this case, reiserfs has the page pinned while it is doing journal
magic. Not sure if ext3 has the same issues.
-chris
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-11-05 10:23 ` Mel Gorman
@ 2007-11-05 22:46 ` Christoph Lameter
-1 siblings, 0 replies; 35+ messages in thread
From: Christoph Lameter @ 2007-11-05 22:46 UTC (permalink / raw)
To: Mel Gorman
Cc: Badari Pulavarty, Chris Mason, reiserfs-devel, linux-mm,
linux-fsdevel
On Mon, 5 Nov 2007, Mel Gorman wrote:
> The grow_dev_page() pages should be reclaimable even though migration
> is not supported for those pages? They were marked movable as it was
> useful for lumpy reclaim taking back pages for hugepage allocations and
> the like. Would it make sense for memory unremove to attempt migration
> first and reclaim second?
Note that a page is still movable even if there is no file system method
for migration available. In that case the page needs to be cleaned before
it can be moved.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-05 22:46 ` Christoph Lameter
0 siblings, 0 replies; 35+ messages in thread
From: Christoph Lameter @ 2007-11-05 22:46 UTC (permalink / raw)
To: Mel Gorman
Cc: Badari Pulavarty, Chris Mason, reiserfs-devel, linux-mm,
linux-fsdevel
On Mon, 5 Nov 2007, Mel Gorman wrote:
> The grow_dev_page() pages should be reclaimable even though migration
> is not supported for those pages? They were marked movable as it was
> useful for lumpy reclaim taking back pages for hugepage allocations and
> the like. Would it make sense for memory unremove to attempt migration
> first and reclaim second?
Note that a page is still movable even if there is no file system method
for migration available. In that case the page needs to be cleaned before
it can be moved.
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-11-05 22:46 ` Christoph Lameter
@ 2007-11-07 14:56 ` Mel Gorman
-1 siblings, 0 replies; 35+ messages in thread
From: Mel Gorman @ 2007-11-07 14:56 UTC (permalink / raw)
To: Christoph Lameter
Cc: Badari Pulavarty, Chris Mason, reiserfs-devel, linux-mm,
linux-fsdevel
On (05/11/07 14:46), Christoph Lameter didst pronounce:
> On Mon, 5 Nov 2007, Mel Gorman wrote:
>
> > The grow_dev_page() pages should be reclaimable even though migration
> > is not supported for those pages? They were marked movable as it was
> > useful for lumpy reclaim taking back pages for hugepage allocations and
> > the like. Would it make sense for memory unremove to attempt migration
> > first and reclaim second?
>
> Note that a page is still movable even if there is no file system method
> for migration available. In that case the page needs to be cleaned before
> it can be moved.
>
Badari, do you know if the pages failed to migrate because they were
dirty or because the filesystem simply had ownership of the pages and
wouldn't let them go?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-07 14:56 ` Mel Gorman
0 siblings, 0 replies; 35+ messages in thread
From: Mel Gorman @ 2007-11-07 14:56 UTC (permalink / raw)
To: Christoph Lameter
Cc: Badari Pulavarty, Chris Mason, reiserfs-devel, linux-mm,
linux-fsdevel
On (05/11/07 14:46), Christoph Lameter didst pronounce:
> On Mon, 5 Nov 2007, Mel Gorman wrote:
>
> > The grow_dev_page() pages should be reclaimable even though migration
> > is not supported for those pages? They were marked movable as it was
> > useful for lumpy reclaim taking back pages for hugepage allocations and
> > the like. Would it make sense for memory unremove to attempt migration
> > first and reclaim second?
>
> Note that a page is still movable even if there is no file system method
> for migration available. In that case the page needs to be cleaned before
> it can be moved.
>
Badari, do you know if the pages failed to migrate because they were
dirty or because the filesystem simply had ownership of the pages and
wouldn't let them go?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
2007-11-07 14:56 ` Mel Gorman
(?)
@ 2007-11-07 15:58 ` Badari Pulavarty
-1 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-07 15:58 UTC (permalink / raw)
To: Mel Gorman
Cc: Christoph Lameter, Chris Mason, reiserfs-devel, linux-mm,
linux-fsdevel
On Wed, 2007-11-07 at 14:56 +0000, Mel Gorman wrote:
> On (05/11/07 14:46), Christoph Lameter didst pronounce:
> > On Mon, 5 Nov 2007, Mel Gorman wrote:
> >
> > > The grow_dev_page() pages should be reclaimable even though migration
> > > is not supported for those pages? They were marked movable as it was
> > > useful for lumpy reclaim taking back pages for hugepage allocations and
> > > the like. Would it make sense for memory unremove to attempt migration
> > > first and reclaim second?
> >
> > Note that a page is still movable even if there is no file system method
> > for migration available. In that case the page needs to be cleaned before
> > it can be moved.
> >
>
> Badari, do you know if the pages failed to migrate because they were
> dirty or because the filesystem simply had ownership of the pages and
> wouldn't let them go?
From the debug, it looks like all the buffers are clean and they
have a b_count == 1. So drop_buffers() fails to release the buffer.
Thanks,
Badari
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-07 15:58 ` Badari Pulavarty
0 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-07 15:58 UTC (permalink / raw)
To: Mel Gorman
Cc: Christoph Lameter, Chris Mason, reiserfs-devel, linux-mm,
linux-fsdevel
On Wed, 2007-11-07 at 14:56 +0000, Mel Gorman wrote:
> On (05/11/07 14:46), Christoph Lameter didst pronounce:
> > On Mon, 5 Nov 2007, Mel Gorman wrote:
> >
> > > The grow_dev_page() pages should be reclaimable even though migration
> > > is not supported for those pages? They were marked movable as it was
> > > useful for lumpy reclaim taking back pages for hugepage allocations and
> > > the like. Would it make sense for memory unremove to attempt migration
> > > first and reclaim second?
> >
> > Note that a page is still movable even if there is no file system method
> > for migration available. In that case the page needs to be cleaned before
> > it can be moved.
> >
>
> Badari, do you know if the pages failed to migrate because they were
> dirty or because the filesystem simply had ownership of the pages and
> wouldn't let them go?
>From the debug, it looks like all the buffers are clean and they
have a b_count == 1. So drop_buffers() fails to release the buffer.
Thanks,
Badari
--
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>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: migratepage failures on reiserfs
@ 2007-11-07 15:58 ` Badari Pulavarty
0 siblings, 0 replies; 35+ messages in thread
From: Badari Pulavarty @ 2007-11-07 15:58 UTC (permalink / raw)
To: Mel Gorman
Cc: Christoph Lameter, Chris Mason, reiserfs-devel, linux-mm,
linux-fsdevel
On Wed, 2007-11-07 at 14:56 +0000, Mel Gorman wrote:
> On (05/11/07 14:46), Christoph Lameter didst pronounce:
> > On Mon, 5 Nov 2007, Mel Gorman wrote:
> >
> > > The grow_dev_page() pages should be reclaimable even though migration
> > > is not supported for those pages? They were marked movable as it was
> > > useful for lumpy reclaim taking back pages for hugepage allocations and
> > > the like. Would it make sense for memory unremove to attempt migration
> > > first and reclaim second?
> >
> > Note that a page is still movable even if there is no file system method
> > for migration available. In that case the page needs to be cleaned before
> > it can be moved.
> >
>
> Badari, do you know if the pages failed to migrate because they were
> dirty or because the filesystem simply had ownership of the pages and
> wouldn't let them go?
>From the debug, it looks like all the buffers are clean and they
have a b_count == 1. So drop_buffers() fails to release the buffer.
Thanks,
Badari
^ permalink raw reply [flat|nested] 35+ messages in thread