[Top] [All Lists]

Re: xfsdump stuck in io_schedule

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: xfsdump stuck in io_schedule
From: Zlatko Calusic <zlatko.calusic@xxxxxxxx>
Date: Fri, 15 Nov 2002 14:01:51 +0100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20021115135233.A13882@xxxxxxxxxxxxxxxx> (Andi Kleen's message of "Fri, 15 Nov 2002 13:52:33 +0100")
References: <dnfzu3yw8u.fsf@xxxxxxxxxxxxxxxxx> <20021115135233.A13882@xxxxxxxxxxxxxxxx>
Reply-to: zlatko.calusic@xxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Honest Recruiter, i386-debian-linux)
Andi Kleen <ak@xxxxxxx> writes:

>> xfsdump: page allocation failure. order:0, mode:0x0
>> xfsdump: page allocation failure. order:0, mode:0x0
>> ...
> It somehow manages to run out of memory and then blocks trying to free some.
> You can do cat /proc/slabinfo and see if there are any suspicious leaks of 
> objects (compare before and after dump) You can also do Shift-ScrLock on 
> the console to dump some memory information and run vmstat doing the dump.

Yes, I'll try to see if slabinfo can discover any leak, although I'm
not quite sure we have a leak problem here, it's more like some part of xfs code
tries to allocate memory too fast, and kernel cannot cope with the
speed. Or similar...

> The 2.5 VM is still rather untuned, so you may just run into some generic
> VM problem. 

I agree. What points me to this list is that I observed such behavior
only with xfsdump. Although 2.5 is still in development phase, VM has
been really stable recently. But yes, it's possible that this is a
genuine kernel VM bug, and xfsdump just triggers it.


<Prev in Thread] Current Thread [Next in Thread>