[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071216135112.0b58ab74.akpm@linux-foundation.org>
Date: Sun, 16 Dec 2007 13:51:12 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Krzysztof Oledzki <olel@....pl>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Osterried <osterried@...se.de>, protasnb@...il.com,
bugme-daemon@...zilla.kernel.org
Subject: Re: [Bug 9182] Critical memory leak (dirty pages)
On Sun, 16 Dec 2007 14:46:36 +0100 (CET) Krzysztof Oledzki <olel@....pl> wrote:
> >>> Which filesystem, which mount options
> >>
> >> - ext3 on RAID1 (MD): / - rootflags=data=journal
> >
> > It wouldn't surprise me if this is specific to data=journal: that
> > journalling mode is pretty complex wrt dairty-data handling and isn't well
> > tested.
> >
> > Does switching that to data=writeback change things?
>
> I'll confirm this tomorrow but it seems that even switching to
> data=ordered (AFAIK default o ext3) is indeed enough to cure this problem.
yes, sorry, I meant ordered.
> Two questions remain then: why system dies when dirty reaches ~200MB
I think you have ~2G of RAM and you're running with
/proc/sys/vm/dirty_ratio=10, yes?
If so, when that machine hits 10% * 2G of dirty memory then everyone who
wants to dirty pages gets blocked.
> and what is wrong with ext3+data=journal with >=2.6.20-rc2?
Ah. It has a bug in it ;)
As I said, data=journal has exceptional handling of pagecache data and is
not well tested. Someone (and I'm not sure who) will need to get in there
and fix it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists