[lkml]   [2001]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Ext2-devel] Re: 2.4.6 and ext3-2.4-0.9.1-246

On Fri, Jul 13, 2001 at 12:27:33PM -0500, Steve Lord wrote:

> We seem to have managed to keep XFS going without the memory reservation
> scheme - and the way we do I/O on metadata right now means there is always
> a memory allocation in that path. At the moment the only thing I can kill
> the system with is make -j bzImage it eventually grinds to a halt with
> the swapper waiting for a request slot in the block layer but the system
> is in such a mess that I have not been able to diagnose it further than
> that.

That I can certainly reproduce. Cerberus is also capable of
reproducing a stall after a few hours. I'm usually seeing
create_buffers() as the place where the kswapd itself is deadlocked,

It does need a _really_ high load to trigger this, though. A 200
client dbench won't do it --- there are too many IOs slowing each
process up. However, Cerberus, which produces a high VM load in
parallel with the IO stress, seems pretty good at triggering the

It also does seem worse on highmem machines, almost certainly because
of zone imbalance problems: Marcelo has just started looking more
closely at that as a result of the fine-grained VM monitoring patch
(which showed clearly just how imbalanced the VM can get when you have
a highmem zone).

> A lot of careful use of GFP flags on memory allocation was necessary to
> get to this point, the GFP_NOIO and GFP_NOFS finally made this deadlock
> clean.

Yep, with GFP_NOFS I don't see any fs deadlocks, but I'm still seeing
the swapper blocked inside create_buffers (not within ext3 at all).
That's not good.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean