linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Paul Larson <plars@austin.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>
Subject: Re: 0-order allocation failures in LTP run of Last nights bk tree
Date: Fri, 06 Sep 2002 11:58:30 -0700	[thread overview]
Message-ID: <3D78FAD6.269EF2FB@digeo.com> (raw)
In-Reply-To: <1031322426.30394.4.camel@plars.austin.ibm.com>

Paul Larson wrote:
> 
> In the nightly ltp run against the bk 2.5 tree last night I saw this
> show up in the logs.
> 
> It happened on the 2-way PIII-550, 2gb physical ram, but not on the
> smaller UP box I test on.
> 
> mtest01: page allocation failure. order:0, mode:0x50

scsi, I assume?

This will be failed bounce buffer allocation attempts.

That's fine, normal.  block will fall back to the mempool
and will wait.

Of course, your shouldn't be bounce buffering at all.  This
is happening because of the block-highmem problem.  There's
a workaround at 
http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.33/2.5.33-mm4/broken-out/scsi_hack.patch

But please bear in mind, this "page allocation failure" message
is purely a developer diagnostic thing.  The reason it is there
is so that if some random toaster driver oopses over a failure
to handle an allocation failure, the person who reports the bug
can say "I saw an allocation failure and then your driver crashed".
Which tells the driver developer where to look.

Under heavy load, page allocation attempts _will_ fail, and
that's OK.  The mempool-backed memory will become available.

It's a bit CPU-inefficient, and I have code under test which
changes GFP_NOFS mempool allocators to not even bother trying
to enter page reclaim if the nonblocking allocation attempt
failed.
--
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/

      reply	other threads:[~2002-09-06 18:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-06 14:27 Paul Larson
2002-09-06 18:58 ` Andrew Morton [this message]

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=3D78FAD6.269EF2FB@digeo.com \
    --to=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=plars@austin.ibm.com \
    /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