Re: migratepage failures on reiserfs

Re: migratepage failures on reiserfs

[Chris Mason]

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

Re: migratepage failures on reiserfs

[Chris Mason]

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

--
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>

migratepage failures on reiserfs

[Badari Pulavarty]

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 ? 

Thanks,
Badari 

migratepage failures on reiserfs

[Badari Pulavarty]

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 ? 

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>

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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

Thanks,
Badari

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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

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>

Re: migratepage failures on reiserfs

[Chris Mason]

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

Re: migratepage failures on reiserfs

[Chris Mason]

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>

Re: migratepage failures on reiserfs

[Badari]

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

Re: migratepage failures on reiserfs

[Badari]

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>

Re: migratepage failures on reiserfs

[Zan Lynx]

[-- 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 --]

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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>

Re: migratepage failures on reiserfs

[Chris Mason]

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

Re: migratepage failures on reiserfs

[Chris Mason]

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>

Re: migratepage failures on reiserfs

[Chris Mason]

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

Re: migratepage failures on reiserfs

[Chris Mason]

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>

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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>

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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>

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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>

Re: migratepage failures on reiserfs

[Mel Gorman]

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

Re: migratepage failures on reiserfs

[Mel Gorman]

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>

Re: migratepage failures on reiserfs

[Chris Mason]

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

Re: migratepage failures on reiserfs

[Chris Mason]

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>

Re: migratepage failures on reiserfs

[Chris Mason]

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

Re: migratepage failures on reiserfs

[Christoph Lameter]

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.

Re: migratepage failures on reiserfs

[Christoph Lameter]

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>

Re: migratepage failures on reiserfs

[Mel Gorman]

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

Re: migratepage failures on reiserfs

[Mel Gorman]

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>

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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>

Re: migratepage failures on reiserfs

[Badari Pulavarty]

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