From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Stefan Schmidt <zaphodb@zaphods.net>
Cc: Nick Piggin <piggin@cyberone.com.au>,
Lukas Hejtmanek <xhejtman@mail.muni.cz>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures
Date: Tue, 16 Nov 2004 07:33:11 -0200 [thread overview]
Message-ID: <20041116093311.GD11482@logos.cnet> (raw)
In-Reply-To: <20041113144743.GL20754@zaphods.net>
On Sat, Nov 13, 2004 at 03:47:43PM +0100, Stefan Schmidt wrote:
> On Fri, Nov 12, 2004 at 11:09:29PM +1100, Nick Piggin wrote:
> > OK. Occasional page allocation failures are not a problem, although
> > if it is an order-0 allocation it may be an idea to increase
> > min_free_kbytes a bit more.
> What about more than occasional but more like constant errors? ;)
>
> > I think you said earlier that you had min_free_kbytes set to 8192?
> > Well after applying my patch, the memory watermarks get squashed
> > down, so you'd want to set it to at least 16384 afterward. Maybe
> > more.
> I took the default from 2.6.10-rc1-bk19 with your patch and doubled it. No
> luck with the following values subsequently applied:
> #vm.min_free_kbytes=3831
> #vm.min_free_kbytes=7662
> #vm.min_free_kbytes=15324
> #vm.min_free_kbytes=61296
> vm.min_free_kbytes=65535
> Did not help against the page allocation errors or boosting up the machines
> performance.
Nick, such high reservations should have protected the system from OOM.
> I got XFS filesystem corruption in the end which (just) perhaps was triggered by
> page allocation errors for it says:
> XFS internal error XFS_WANT_CORRUPTED_RETURN after several page allocation
> errors for the application having XFS in its stack trace leading to:
> kernel: xfs_force_shutdown(sdd5,0x8) called from line 1091 of file
> fs/xfs/xfs_trans.c. Return address = 0xc0212e5c
> kernel: Filesystem "sdd5": Corruption of in-memory data detected.
> Shutting down filesystem: sdd5
> kernel: Please umount the filesystem, and rectify the problem(s)
>
> Corruption of in-memory data sounds like something we would not want to
> happen, right?
Definately. I suspect XFS is unable to handle OOM graciously, or some other
problem.
> I attached full traces to http://oss.sgi.com/bugzilla/show_bug.cgi?id=345 which
> is an rather old ticket dealing with page allocation errors and xfs but
> perhaps it does fit.
>
> Stefan
next prev parent reply other threads:[~2004-11-16 13:27 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-03 22:24 Kernel 2.6.9 Multiple Page Allocation Failures (Part 2) Stefan Schmidt
2004-11-04 12:17 ` Marcelo Tosatti
2004-11-04 18:18 ` Stefan Schmidt
2004-11-09 16:41 ` Kernel 2.6.9 Multiple Page Allocation Failures Marcelo Tosatti
2004-11-09 22:35 ` Lukas Hejtmanek
2004-11-09 22:46 ` Andrew Morton
2004-11-09 22:44 ` Lukas Hejtmanek
2004-11-09 20:33 ` Marcelo Tosatti
2004-11-10 20:35 ` Lukas Hejtmanek
2004-11-10 21:09 ` Andrew Morton
2004-11-10 21:24 ` Lukas Hejtmanek
2004-11-10 21:47 ` Andrew Morton
2004-11-10 21:28 ` Lukas Hejtmanek
2004-11-10 18:11 ` Marcelo Tosatti
2004-11-11 1:04 ` Lukas Hejtmanek
2004-11-11 21:44 ` Lukas Hejtmanek
2004-11-12 12:09 ` Nick Piggin
2004-11-13 14:47 ` Stefan Schmidt
2004-11-16 9:33 ` Marcelo Tosatti [this message]
2004-11-16 17:05 ` Lukas Hejtmanek
2004-11-21 1:43 ` Stefan Schmidt
2004-11-21 2:42 ` Stefan Schmidt
2004-12-02 19:54 ` Lukas Hejtmanek
2004-12-02 20:25 ` Andrew Morton
2004-12-02 21:03 ` Lukas Hejtmanek
2004-12-02 22:31 ` Stefan Schmidt
2004-12-02 22:48 ` Lukas Hejtmanek
2004-12-02 22:56 ` Andrew Morton
2004-12-02 23:18 ` Lukas Hejtmanek
2004-12-03 0:18 ` Andrew Morton
2004-12-03 12:11 ` Lukas Hejtmanek
2004-12-03 12:17 ` Lukas Hejtmanek
2004-12-07 22:52 ` Nick Piggin
2004-12-07 22:59 ` Lukas Hejtmanek
2004-12-07 23:05 ` Nick Piggin
2004-12-08 11:18 ` Lukas Hejtmanek
2004-12-08 11:23 ` Nick Piggin
2004-12-08 11:46 ` Lukas Hejtmanek
2004-12-08 13:14 ` Lukas Hejtmanek
2004-12-09 8:52 ` Nick Piggin
2004-12-09 9:02 ` Lukas Hejtmanek
2004-12-09 10:29 ` Nick Piggin
2004-12-09 10:37 ` Lukas Hejtmanek
2004-12-03 6:18 ` Nathan Scott
2004-12-03 7:06 ` Andrew Morton
2004-12-07 11:17 ` Lukas Hejtmanek
2004-12-08 0:15 ` Nathan Scott
2004-12-08 0:36 ` Lukas Hejtmanek
2004-12-03 10:35 ` Christoph Hellwig
2004-12-03 10:58 ` P
2004-12-03 17:11 ` Andrew Morton
2004-11-09 23:52 ` Stefan Schmidt
2004-11-10 1:27 ` 2.6.10-rc1-mm4 -1 EAGAIN after allocation failure was: " Stefan Schmidt
2004-11-10 1:39 ` Andrew Morton
2004-11-10 2:03 ` Stefan Schmidt
2004-11-10 2:21 ` Andrew Morton
2004-11-10 4:24 ` Nick Piggin
2004-11-10 10:28 ` Stefan Schmidt
2004-11-10 12:06 ` Stefan Schmidt
2004-11-10 8:58 ` Marcelo Tosatti
2004-11-10 12:48 ` Stefan Schmidt
2004-11-10 10:56 ` Marcelo Tosatti
2004-11-11 1:23 ` Nick Piggin
2004-11-11 18:31 ` jhigdon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041116093311.GD11482@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
--cc=xhejtman@mail.muni.cz \
--cc=zaphodb@zaphods.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox